Đây là một điều mình nhận ra sau khi làm và hướng dẫn nhiều bài lab về Azure.
Khi một Virtual Machine không thể SSH hoặc Remote Desktop, phản ứng đầu tiên của rất nhiều người là:
Nhưng trong rất nhiều trường hợp...
Virtual Machine hoàn toàn không phải là vấn đề.
Hãy tưởng tượng một tình huống rất thực tế.
Virtual Machine đang Running.
Public IP đã được cấp.
CPU và RAM hoạt động bình thường.
Nhưng người dùng vẫn không thể kết nối.
Nếu chỉ nhìn vào Virtual Machine, bạn sẽ mất rất nhiều thời gian để kiểm tra những thứ vốn không hề có lỗi.
Bởi vì trên Azure, trước khi một gói tin đến được Virtual Machine, nó còn phải đi qua rất nhiều "cánh cửa".
Internet
↓
Public IP
↓
Network Security Group (NSG)
↓
Route Table
↓
Subnet
↓
Network Interface (NIC)
↓
Virtual Machine
Chỉ cần một cánh cửa đóng lại.
Toàn bộ kết nối sẽ thất bại.
Đó là lý do một Azure Administrator có kinh nghiệm thường không hỏi:
"VM có đang chạy không?"
Mà sẽ hỏi:
"Gói tin đang bị chặn ở đâu?"
Đó là hai cách tư duy hoàn toàn khác nhau.
Đây cũng là điều mình đánh giá rất cao ở Lab 04 – Implement Virtual Networks trong chương trình AZ-104.
Thoạt nhìn, bài lab chỉ là tạo Virtual Network và Subnet.
Nhưng nếu học đúng cách, bạn sẽ nhận ra mục tiêu của bài lab không phải là tạo được một VNet.
Mà là hiểu đường đi của lưu lượng trong Azure.
Bạn sẽ biết:
Mình luôn nghĩ rằng:
Cloud không làm Networking biến mất.
Cloud chỉ khiến Networking trở nên trừu tượng hơn.
Bạn không còn nhìn thấy switch, router hay dây mạng.
Nhưng chúng vẫn tồn tại dưới một hình thức khác.
Nếu không hiểu những thành phần đó đang hoạt động như thế nào, việc triển khai Virtual Machine sẽ chỉ dừng lại ở mức "biết bấm nút tạo".
Còn để vận hành một hệ thống Azure ổn định, điều quan trọng hơn là hiểu gói tin đang đi như thế nào.
Nếu một Virtual Machine trên Azure có đầy đủ:
Bạn sẽ kiểm tra thành phần nào đầu tiên?
Cùng chia sẻ góc nhìn của mình ở phần bình luận nhé. Biết đâu mỗi người sẽ có một quy trình troubleshooting khác nhau và đó chính là điều thú vị khi làm hạ tầng.
Khi một Virtual Machine không thể SSH hoặc Remote Desktop, phản ứng đầu tiên của rất nhiều người là:
- Khởi động lại VM.
- Kiểm tra Windows Firewall.
- Kiểm tra dịch vụ RDP hoặc SSH.
- Thậm chí xóa VM và tạo lại.
Nhưng trong rất nhiều trường hợp...
Virtual Machine hoàn toàn không phải là vấn đề.
Hãy tưởng tượng một tình huống rất thực tế.
Virtual Machine đang Running.
Public IP đã được cấp.
CPU và RAM hoạt động bình thường.Nhưng người dùng vẫn không thể kết nối.
Nếu chỉ nhìn vào Virtual Machine, bạn sẽ mất rất nhiều thời gian để kiểm tra những thứ vốn không hề có lỗi.
Bởi vì trên Azure, trước khi một gói tin đến được Virtual Machine, nó còn phải đi qua rất nhiều "cánh cửa".
Internet↓
Public IP
↓
Network Security Group (NSG)
↓
Route Table
↓
Subnet
↓
Network Interface (NIC)
↓
Virtual Machine
Chỉ cần một cánh cửa đóng lại.
Toàn bộ kết nối sẽ thất bại.
Đó là lý do một Azure Administrator có kinh nghiệm thường không hỏi:
"VM có đang chạy không?"
Mà sẽ hỏi:
"Gói tin đang bị chặn ở đâu?"
Đó là hai cách tư duy hoàn toàn khác nhau.
Đây cũng là điều mình đánh giá rất cao ở Lab 04 – Implement Virtual Networks trong chương trình AZ-104.
Thoạt nhìn, bài lab chỉ là tạo Virtual Network và Subnet.
Nhưng nếu học đúng cách, bạn sẽ nhận ra mục tiêu của bài lab không phải là tạo được một VNet.
Mà là hiểu đường đi của lưu lượng trong Azure.
Bạn sẽ biết:
- Vì sao VM có Public IP nhưng vẫn không truy cập được.
- NSG nên đặt ở Subnet hay Network Interface?
- Khi nào cần Route Table?
- Vì sao cùng một cấu hình nhưng VM này truy cập được, VM khác thì không?
- Nên bắt đầu troubleshooting từ đâu để không mất hàng chục phút kiểm tra sai hướng?
Mình luôn nghĩ rằng:
Cloud không làm Networking biến mất.Cloud chỉ khiến Networking trở nên trừu tượng hơn.
Bạn không còn nhìn thấy switch, router hay dây mạng.
Nhưng chúng vẫn tồn tại dưới một hình thức khác.
Nếu không hiểu những thành phần đó đang hoạt động như thế nào, việc triển khai Virtual Machine sẽ chỉ dừng lại ở mức "biết bấm nút tạo".
Còn để vận hành một hệ thống Azure ổn định, điều quan trọng hơn là hiểu gói tin đang đi như thế nào.
Nếu một Virtual Machine trên Azure có đầy đủ:- Public IP
- Trạng thái Running
- NSG đã cho phép cổng 3389
Bạn sẽ kiểm tra thành phần nào đầu tiên?Cùng chia sẻ góc nhìn của mình ở phần bình luận nhé. Biết đâu mỗi người sẽ có một quy trình troubleshooting khác nhau và đó chính là điều thú vị khi làm hạ tầng.