Quy mô của mạng Amazon Web Services là 69 khu vực trên toàn thế giới ở 22 khu vực: Hoa Kỳ, Châu Âu, Châu Á, Châu Phi và Úc. Mỗi vùng chứa tối đa 8 trung tâm dữ liệu - Data Treatment Centers. Mỗi trung tâm dữ liệu có hàng nghìn hoặc hàng trăm nghìn máy chủ. Mạng được thiết kế sao cho tất cả các tình huống ngừng hoạt động không thể xảy ra đều được tính đến. Ví dụ: tất cả các khu vực đều bị cô lập với nhau và các khu vực tiếp cận được tách biệt trong khoảng cách vài km. Ngay cả khi bạn cắt cáp, hệ thống sẽ chuyển sang các kênh dự phòng và việc mất thông tin sẽ lên tới một vài gói dữ liệu. Vasily Pantyukhin sẽ nói về những nguyên tắc khác mà mạng được xây dựng dựa trên đó và nó được cấu trúc như thế nào.
Vasily Pantyukhin bắt đầu với tư cách là quản trị viên Unix trong các công ty .ru, làm việc trên phần cứng lớn của Sun Microsystem trong 6 năm và thuyết giảng về thế giới lấy dữ liệu làm trung tâm trong 11 năm tại EMC. Nó tự nhiên phát triển thành các đám mây riêng, sau đó chuyển sang đám mây công cộng. Hiện tại, với tư cách là kiến trúc sư của Amazon Web Services, anh đưa ra lời khuyên kỹ thuật để giúp tồn tại và phát triển trên đám mây AWS.
Trong phần trước của bộ ba AWS, Vasily đã đi sâu vào thiết kế máy chủ vật lý và mở rộng quy mô cơ sở dữ liệu. Thẻ nitro, trình ảo hóa dựa trên KVM tùy chỉnh, cơ sở dữ liệu Amazon Aurora - về tất cả những điều này trong tài liệu "" Đọc để biết ngữ cảnh hoặc xem bài phát biểu.
Phần này sẽ tập trung vào việc mở rộng quy mô mạng, một trong những hệ thống phức tạp nhất trong AWS. Sự phát triển từ mạng phẳng sang Đám mây riêng ảo và thiết kế của nó, các dịch vụ nội bộ của Blackfoot và HyperPlane, vấn đề hàng xóm ồn ào và cuối cùng - quy mô của mạng, đường trục và cáp vật lý. Về tất cả điều này dưới vết cắt.
Tuyên bố miễn trừ trách nhiệm: mọi thứ bên dưới là ý kiến cá nhân của Vasily và có thể không trùng với quan điểm của Amazon Web Services.
Mở rộng quy mô mạng
Đám mây AWS được ra mắt vào năm 2006. Mạng của ông khá nguyên thủy - với cấu trúc phẳng. Phạm vi địa chỉ riêng tư là phổ biến đối với tất cả người thuê đám mây. Khi khởi động một máy ảo mới, bạn vô tình nhận được một địa chỉ IP khả dụng từ dải này.
Cách tiếp cận này dễ thực hiện nhưng về cơ bản đã hạn chế việc sử dụng đám mây. Đặc biệt, việc phát triển các giải pháp lai kết hợp mạng riêng trên mặt đất và trong AWS là khá khó khăn. Vấn đề phổ biến nhất là phạm vi địa chỉ IP bị chồng chéo.
Đám mây riêng ảo
Đám mây hóa ra đang có nhu cầu. Đã đến lúc phải suy nghĩ về khả năng mở rộng và khả năng sử dụng nó của hàng chục triệu người thuê. Mạng phẳng đã trở thành một trở ngại lớn. Do đó, chúng tôi đã nghĩ đến cách tách biệt người dùng với nhau ở cấp độ mạng để họ có thể chọn dải IP một cách độc lập.
Điều đầu tiên bạn nghĩ đến khi nghĩ đến việc cách ly mạng là gì? Chắc chắn VLAN и VRF - Định tuyến và chuyển tiếp ảo.
Thật không may, nó không hoạt động. VLAN ID chỉ có 12 bit, chỉ cung cấp cho chúng ta 4096 phân đoạn riêng biệt. Ngay cả những thiết bị chuyển mạch lớn nhất cũng có thể sử dụng tối đa 1-2 nghìn VRF. Việc sử dụng VRF và VLAN cùng nhau chỉ mang lại cho chúng ta vài triệu mạng con. Điều này chắc chắn là không đủ đối với hàng chục triệu người thuê, mỗi người trong số họ phải có khả năng sử dụng nhiều mạng con.
Đơn giản là chúng tôi không đủ khả năng để mua số lượng hộp lớn cần thiết, chẳng hạn như từ Cisco hoặc Juniper. Có hai lý do: nó quá đắt và chúng tôi không muốn phụ thuộc vào chính sách phát triển và vá lỗi của họ.
Chỉ có một kết luận - hãy đưa ra giải pháp của riêng bạn.
Năm 2009 chúng tôi đã công bố VPC - Đám mây riêng ảo. Cái tên này đã bị mắc kẹt và hiện nay nhiều nhà cung cấp dịch vụ đám mây cũng sử dụng nó.
VPC là mạng ảo SDN (Mạng được xác định bằng phần mềm). Chúng tôi quyết định không phát minh ra các giao thức đặc biệt ở cấp độ L2 và L3. Mạng chạy trên Ethernet và IP tiêu chuẩn. Để truyền qua mạng, lưu lượng máy ảo được gói gọn trong trình bao bọc giao thức của riêng chúng tôi. Nó cho biết ID thuộc về VPC của đối tượng thuê.
Nghe có vẻ đơn giản. Tuy nhiên, có một số thách thức kỹ thuật nghiêm trọng cần phải vượt qua. Ví dụ: vị trí và cách lưu trữ dữ liệu về ánh xạ địa chỉ MAC/IP ảo, ID VPC và MAC/IP vật lý tương ứng. Trên quy mô AWS, đây là một bảng lớn sẽ hoạt động với độ trễ truy cập ở mức tối thiểu. Chịu trách nhiệm về việc này dịch vụ bản đồ, được trải thành một lớp mỏng trên toàn mạng.
Trong các máy thế hệ mới, việc đóng gói được thực hiện bằng thẻ Nitro ở cấp độ phần cứng. Trong các trường hợp cũ hơn, việc đóng gói và giải mã đều dựa trên phần mềm.
Hãy tìm hiểu cách nó hoạt động nói chung. Hãy bắt đầu với cấp độ L2. Giả sử rằng chúng ta có một máy ảo có IP 10.0.0.2 trên máy chủ vật lý 192.168.0.3. Nó gửi dữ liệu đến máy ảo 10.0.0.3, có địa chỉ 192.168.1.4. Yêu cầu ARP được tạo và gửi tới thẻ Nitro mạng. Để đơn giản, chúng tôi giả định rằng cả hai máy ảo đều hoạt động trong cùng một VPC “xanh”.
Bản đồ thay thế địa chỉ nguồn bằng địa chỉ của chính nó và chuyển tiếp khung ARP tới dịch vụ ánh xạ.
Dịch vụ ánh xạ trả về thông tin cần thiết để truyền qua mạng vật lý L2.
Thẻ Nitro trong phản hồi ARP thay thế MAC trên mạng vật lý bằng địa chỉ trong VPC.
Khi truyền dữ liệu, chúng tôi bọc MAC và IP logic trong trình bao bọc VPC. Chúng tôi truyền tải tất cả điều này qua mạng vật lý bằng cách sử dụng thẻ IP Nitro nguồn và đích thích hợp.
Máy vật lý chứa gói tin sẽ thực hiện việc kiểm tra. Điều này là cần thiết để ngăn chặn khả năng giả mạo địa chỉ. Máy gửi yêu cầu đặc biệt đến dịch vụ ánh xạ và hỏi: “Từ máy vật lý 192.168.0.3, tôi đã nhận được gói dành cho 10.0.0.3 trong VPC màu xanh lam. Anh ấy có hợp pháp không?
Dịch vụ ánh xạ kiểm tra bảng phân bổ tài nguyên của nó và cho phép hoặc từ chối gói đi qua. Trong tất cả các trường hợp mới, xác thực bổ sung được nhúng vào thẻ Nitro. Không thể bỏ qua nó ngay cả về mặt lý thuyết. Do đó, việc giả mạo tài nguyên trong một VPC khác sẽ không hoạt động.
Tiếp theo, dữ liệu được gửi đến máy ảo dự kiến.
Dịch vụ ánh xạ cũng hoạt động như một bộ định tuyến logic để truyền dữ liệu giữa các máy ảo trong các mạng con khác nhau. Mọi thứ đều đơn giản về mặt khái niệm, tôi sẽ không đi vào chi tiết.
Hóa ra khi truyền từng gói tin, các máy chủ sẽ chuyển sang dịch vụ bản đồ. Làm thế nào để đối phó với sự chậm trễ không thể tránh khỏi? Bộ nhớ đệm, tất nhiên rồi.
Điều thú vị là bạn không cần phải lưu toàn bộ bảng lớn vào bộ nhớ đệm. Một máy chủ vật lý lưu trữ các máy ảo từ một số lượng VPC tương đối nhỏ. Bạn chỉ cần lưu vào bộ nhớ đệm thông tin về các VPC này. Việc truyền dữ liệu sang các VPC khác ở cấu hình “mặc định” vẫn không hợp pháp. Nếu chức năng như VPC-peering được sử dụng thì thông tin về các VPC tương ứng sẽ được tải thêm vào bộ đệm.
Chúng tôi đã sắp xếp việc chuyển dữ liệu sang VPC.
Chân đen
Phải làm gì trong trường hợp lưu lượng cần truyền ra bên ngoài, ví dụ như Internet hoặc qua VPN xuống mặt đất? Giúp chúng tôi ở đây Chân đen — Dịch vụ nội bộ của AWS. Nó được phát triển bởi nhóm Nam Phi của chúng tôi. Đó là lý do tại sao dịch vụ này được đặt theo tên của một chú chim cánh cụt sống ở Nam Phi.
Blackfoot giải mã lưu lượng truy cập và thực hiện những gì cần thiết với nó. Dữ liệu được gửi tới Internet như cũ.
Dữ liệu được giải mã và gói lại trong IPsec khi sử dụng VPN.
Khi sử dụng Direct Connect, lưu lượng được gắn thẻ và gửi đến VLAN thích hợp.
siêu phẳng
Đây là một dịch vụ kiểm soát luồng nội bộ. Nhiều dịch vụ mạng yêu cầu giám sát trạng thái luồng dữ liệu. Ví dụ: khi sử dụng NAT, điều khiển luồng phải đảm bảo rằng mỗi cặp cổng IP:đích có một cổng đi duy nhất. Trong trường hợp bộ cân bằng NLB - Cân bằng tải mạng, luồng dữ liệu phải luôn được hướng đến cùng một máy ảo đích. Nhóm bảo mật là một tường lửa có trạng thái. Nó giám sát lưu lượng đến và ngầm mở các cổng cho luồng gói đi.
Trong đám mây AWS, yêu cầu về độ trễ truyền là cực kỳ cao. Đó là lý do tại sao siêu phẳng quan trọng đối với hiệu suất của toàn bộ mạng.
Siêu phẳng được xây dựng trên máy ảo EC2. Không có phép thuật ở đây, chỉ có sự xảo quyệt. Bí quyết là đây là những máy ảo có RAM lớn. Các hoạt động mang tính giao dịch và được thực hiện độc quyền trong bộ nhớ. Điều này cho phép bạn đạt được độ trễ chỉ hàng chục micro giây. Làm việc với đĩa sẽ giết chết mọi năng suất.
Siêu phẳng là một hệ thống phân tán gồm một số lượng lớn các máy EC2 như vậy. Mỗi máy ảo có băng thông 5 GB/s. Trên toàn bộ mạng khu vực, điều này cung cấp băng thông lên tới hàng terabit đáng kinh ngạc và cho phép xử lý hàng triệu kết nối mỗi giây.
HyperPlane chỉ hoạt động với các luồng. Việc đóng gói gói VPC hoàn toàn trong suốt đối với nó. Một lỗ hổng tiềm ẩn trong dịch vụ nội bộ này vẫn có thể khiến tính năng cách ly VPC không bị phá vỡ. Các cấp dưới đây chịu trách nhiệm về an ninh.
hàng xóm ồn ào
Vẫn còn một vấn đề hàng xóm ồn ào - hàng xóm ồn ào. Giả sử chúng ta có 8 nút. Các nút này xử lý luồng của tất cả người dùng đám mây. Mọi thứ dường như đều ổn và tải sẽ được phân bổ đều trên tất cả các nút. Các nút rất mạnh và rất khó để chúng bị quá tải.
Nhưng chúng tôi xây dựng kiến trúc của mình dựa trên những tình huống thậm chí khó xảy ra nhất.
Xác suất thấp không có nghĩa là không thể.
Chúng ta có thể tưởng tượng một tình huống trong đó một hoặc nhiều người dùng sẽ tạo ra quá nhiều tải. Tất cả các nút HyperPlane đều tham gia vào quá trình xử lý tải này và những người dùng khác có thể gặp phải một số ảnh hưởng về hiệu suất. Điều này phá vỡ khái niệm về đám mây, trong đó người thuê không có khả năng ảnh hưởng lẫn nhau.
Làm thế nào để giải quyết vấn đề hàng xóm ồn ào? Điều đầu tiên bạn nghĩ đến là sharding. 8 nút của chúng tôi được chia một cách hợp lý thành 4 phân đoạn, mỗi phân đoạn có 2 nút. Giờ đây, một người hàng xóm ồn ào sẽ chỉ làm phiền một phần tư tổng số người dùng, nhưng nó sẽ làm phiền họ rất nhiều.
Hãy làm mọi việc khác đi. Chúng tôi sẽ chỉ phân bổ 3 nút cho mỗi người dùng.
Bí quyết là gán ngẫu nhiên các nút cho những người dùng khác nhau. Trong hình bên dưới, người dùng màu xanh lam giao các nút với một trong hai người dùng còn lại - màu xanh lá cây và màu cam.
Với 8 nút và 3 người dùng, xác suất hàng xóm ồn ào giao nhau với một trong những người dùng là 54%. Với khả năng này, người dùng màu xanh lam sẽ ảnh hưởng đến những người thuê nhà khác. Đồng thời, chỉ một phần tải của nó. Trong ví dụ của chúng tôi, ảnh hưởng này ít nhất sẽ được chú ý bằng cách nào đó không phải đối với tất cả mọi người mà chỉ đối với một phần ba tổng số người dùng. Đây đã là một kết quả tốt rồi.
Số lượng người dùng sẽ giao nhau
Xác suất tính bằng phần trăm
0
18%
1
54%
2
26%
3
2%
Hãy đưa tình huống đến gần hơn với thực tế - hãy lấy 100 nút và 5 người dùng trên 5 nút. Trong trường hợp này, không có nút nào giao nhau với xác suất là 77%.
Số lượng người dùng sẽ giao nhau
Xác suất tính bằng phần trăm
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Trong tình huống thực tế, với số lượng lớn nút và người dùng HyperPlane, tác động tiềm ẩn của hàng xóm ồn ào đối với những người dùng khác là rất nhỏ. Phương pháp này được gọi là trộn mảnh - phân mảnh ngẫu nhiên. Nó giảm thiểu tác động tiêu cực của lỗi nút.
Nhiều dịch vụ được xây dựng trên nền tảng HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Quy mô mạng
Bây giờ hãy nói về quy mô của mạng. Trong tháng 2019 năm XNUMX, AWS cung cấp dịch vụ của mình tại 22 vùng, và 9 chiếc nữa đã được lên kế hoạch.
- Mỗi khu vực chứa một số Vùng sẵn sàng. Có 69 người trong số họ trên khắp thế giới.
- Mỗi AZ bao gồm các Trung tâm xử lý dữ liệu. Tổng cộng không có nhiều hơn 8 người trong số họ.
- Trung tâm dữ liệu chứa một số lượng lớn máy chủ, một số có tới 300 máy chủ.
Bây giờ, hãy tính trung bình tất cả những điều này, nhân lên và có được một con số ấn tượng phản ánh Quy mô đám mây Amazon.
Có nhiều liên kết quang giữa Vùng sẵn sàng và trung tâm dữ liệu. Tại một trong những khu vực lớn nhất của chúng tôi, 388 kênh đã được thiết lập chỉ để liên lạc giữa AZ với nhau và giữa các trung tâm liên lạc với các khu vực khác (Trung tâm chuyển tuyến). Tổng cộng điều này thật điên rồ 5000 Tbit.
Backbone AWS được xây dựng dành riêng và tối ưu hóa cho đám mây. Chúng tôi xây dựng nó trên các kênh 100 GB / giây. Chúng tôi kiểm soát chúng hoàn toàn, ngoại trừ các khu vực ở Trung Quốc. Lưu lượng truy cập không được chia sẻ với tải của các công ty khác.
Tất nhiên, chúng tôi không phải là nhà cung cấp đám mây duy nhất có mạng đường trục riêng. Ngày càng có nhiều công ty lớn đi theo con đường này. Điều này được xác nhận bởi các nhà nghiên cứu độc lập, ví dụ từ .
Biểu đồ cho thấy tỷ trọng của các nhà cung cấp nội dung và nhà cung cấp đám mây đang tăng lên. Vì điều này, thị phần lưu lượng truy cập Internet của các nhà cung cấp đường trục không ngừng giảm.
Tôi sẽ giải thích tại sao điều này xảy ra. Trước đây, hầu hết các dịch vụ web đều có thể truy cập và sử dụng trực tiếp từ Internet. Ngày nay, ngày càng có nhiều máy chủ được đặt trên đám mây và có thể truy cập được thông qua CDN - Mạng phân phối nội dung. Để truy cập tài nguyên, người dùng chỉ truy cập Internet tới CDN PoP gần nhất - Điểm của sự hiện diện. Thông thường nó ở đâu đó gần đó. Sau đó, nó rời khỏi Internet công cộng và bay qua đường trục riêng qua Đại Tây Dương chẳng hạn, và truy cập trực tiếp vào tài nguyên.
Tôi tự hỏi Internet sẽ thay đổi như thế nào sau 10 năm nữa nếu xu hướng này tiếp tục?
Kênh vật lý
Các nhà khoa học vẫn chưa tìm ra cách tăng tốc độ ánh sáng trong Vũ trụ, nhưng họ đã đạt được tiến bộ lớn trong phương pháp truyền nó qua sợi quang. Chúng tôi hiện đang sử dụng cáp quang 6912. Điều này giúp tối ưu hóa đáng kể chi phí lắp đặt của họ.
Ở một số vùng chúng tôi phải sử dụng các loại cáp đặc biệt. Ví dụ, ở khu vực Sydney, chúng tôi sử dụng dây cáp có lớp phủ đặc biệt chống mối mọt.
Không ai tránh khỏi những rắc rối và đôi khi các kênh của chúng tôi bị hỏng. Bức ảnh bên phải cho thấy cáp quang ở một trong những khu vực của Mỹ bị công nhân xây dựng xé nát. Hậu quả của vụ tai nạn là chỉ có 13 gói dữ liệu bị mất, điều này thật đáng ngạc nhiên. Một lần nữa - chỉ 13! Hệ thống thực sự ngay lập tức chuyển sang các kênh dự phòng - cân đang hoạt động.
Chúng tôi đã lướt qua một số dịch vụ và công nghệ đám mây của Amazon. Tôi hy vọng rằng bạn có ít nhất một số ý tưởng về quy mô của các nhiệm vụ mà các kỹ sư của chúng tôi phải giải quyết. Cá nhân tôi thấy điều này rất thú vị.
Đây là phần cuối cùng trong bộ ba của Vasily Pantyukhin về thiết bị AWS. TRONG các phần mô tả tối ưu hóa máy chủ và mở rộng quy mô cơ sở dữ liệu, đồng thời — chức năng không có máy chủ và Firecracker.
Trên vào tháng 11 Vasily Pantyukhin sẽ chia sẻ thông tin chi tiết mới về thiết bị Amazon. Anh ta về nguyên nhân thất bại và cách thiết kế hệ thống phân tán tại Amazon. Ngày 24 tháng XNUMX vẫn có thể mua vé với giá tốt và thanh toán sau. Chúng tôi đang đợi bạn tại HighLoad++, hãy đến và trò chuyện!
Nguồn: www.habr.com