Amazon Web Services ağının ölçeği dünya çapında 69 bölgede 22 bölgedir: ABD, Avrupa, Asya, Afrika ve Avustralya. Her bölge en fazla 8 veri merkezi içerir - Veri İşleme Merkezleri. Her veri merkezinde binlerce veya yüzbinlerce sunucu bulunur. Ağ, olası tüm kesinti senaryoları dikkate alınacak şekilde tasarlanmıştır. Örneğin, tüm bölgeler birbirinden izole edilmiştir ve erişilebilirlik bölgeleri birkaç kilometrelik mesafelerle ayrılmıştır. Kabloyu kesseniz bile sistem yedek kanallara geçecek ve birkaç veri paketi kadar bilgi kaybı yaşanacaktır. Vasily Pantyukhin, ağın başka hangi ilkeler üzerine kurulduğunu ve nasıl yapılandırıldığını anlatacak.
Vasili Pantyukhin .ru şirketlerinde Unix yöneticisi olarak işe başladı, 6 yıl boyunca büyük Sun Microsystem donanımı üzerinde çalıştı ve EMC'de 11 yıl boyunca veri merkezli bir dünyanın vaazını verdi. Doğal olarak özel bulutlara dönüştü, daha sonra halka açık bulutlara geçti. Artık bir Amazon Web Hizmetleri mimarı olarak AWS bulutunda yaşamaya ve gelişmeye yardımcı olacak teknik tavsiyeler sağlıyor.
AWS üçlemesinin önceki bölümünde Vasily, fiziksel sunucuların tasarımına ve veritabanı ölçeklendirmesine değindi. Nitro kartlar, özel KVM tabanlı hipervizör, Amazon Aurora veritabanı - tüm bunlar hakkında materyalde "" Bağlam için okuyun veya izleyin konuşmalar.
Bu bölümde AWS'deki en karmaşık sistemlerden biri olan ağ ölçeklendirmeye odaklanılacaktır. Düz bir ağdan Sanal Özel Bulut'a geçiş ve tasarımı, Blackfoot ve HyperPlane'in dahili hizmetleri, gürültülü komşu sorunu ve son olarak ağın, omurganın ve fiziksel kabloların ölçeği. Bütün bunlar hakkında kesim altında.
Yasal Uyarı: Aşağıdaki her şey Vasily'nin kişisel görüşüdür ve Amazon Web Services'in konumuyla örtüşmeyebilir.
Ağ ölçeklendirme
AWS bulutu 2006 yılında piyasaya sürüldü. Ağı oldukça ilkeldi; düz bir yapıya sahipti. Özel adres aralığı tüm bulut kiracıları için ortaktı. Yeni bir sanal makine başlatırken yanlışlıkla bu aralıktan kullanılabilir bir IP adresi aldınız.
Bu yaklaşımın uygulanması kolaydı ancak bulutun kullanımı temelde sınırlıydı. Özellikle sahadaki ve AWS'deki özel ağları birleştiren hibrit çözümler geliştirmek oldukça zordu. En yaygın sorun çakışan IP adresi aralıklarıydı.
Sanal Özel Bulut
Bulutun talep gördüğü ortaya çıktı. Ölçeklenebilirlik ve on milyonlarca kiracı tarafından kullanılma olasılığı hakkında düşünmenin zamanı geldi. Düz ağ büyük bir engel haline geldi. Bu nedenle, IP aralıklarını bağımsız olarak seçebilmeleri için kullanıcıları ağ düzeyinde birbirlerinden nasıl yalıtacağımızı düşündük.
Ağ izolasyonu denildiğinde aklınıza gelen ilk şey nedir? Kesinlikle VLAN и VRF - Sanal Yönlendirme ve İletme.
Ne yazık ki işe yaramadı. VLAN ID yalnızca 12 bittir ve bu bize yalnızca 4096 izole bölüm verir. En büyük anahtarlar bile maksimum 1-2 bin VRF kullanabilir. VRF ve VLAN'ı birlikte kullanmak bize yalnızca birkaç milyon alt ağ sağlar. Bu, her biri birden fazla alt ağ kullanabilmesi gereken on milyonlarca kiracı için kesinlikle yeterli değildir.
Ayrıca gerekli sayıda büyük kutuyu örneğin Cisco veya Juniper'dan satın almaya gücümüz yetmez. Bunun iki nedeni var: çok pahalı ve biz onların geliştirme ve yama politikalarının insafına kalmak istemiyoruz.
Tek bir sonuç var; kendi çözümünüzü yaratın.
2009'da duyurduk VPC - Sanal Özel Bulut. Bu isim takıldı ve artık birçok bulut sağlayıcı da bu ismi kullanıyor.
VPC bir sanal ağdır SDN (Yazılım Tanımlı Ağ). L2 ve L3 seviyelerinde özel protokoller icat etmemeye karar verdik. Ağ standart Ethernet ve IP üzerinde çalışır. Ağ üzerinden aktarım için sanal makine trafiği kendi protokol paketleyicimizde kapsüllenir. Kiracının VPC'sine ait olan kimliği belirtir.
Kulağa basit geliyor. Ancak aşılması gereken birçok ciddi teknik zorluk var. Örneğin, sanal MAC/IP adreslerinin, VPC kimliğinin ve karşılık gelen fiziksel MAC/IP'nin eşleştirilmesine ilişkin verilerin nerede ve nasıl depolanacağı. AWS ölçeğinde bu, minimum erişim gecikmesiyle çalışması gereken devasa bir tablodur. Bunun sorumlusu haritalama hizmeti, ağ boyunca ince bir tabaka halinde yayılır.
Yeni nesil makinelerde kapsülleme donanımsal düzeyde Nitro kartlar ile yapılmaktadır. Daha eski örneklerde kapsülleme ve kapsülden çıkarma yazılım tabanlıdır.
Genel anlamda nasıl çalıştığını anlayalım. L2 seviyesiyle başlayalım. 10.0.0.2 fiziksel sunucusunda IP 192.168.0.3 olan bir sanal makinemiz olduğunu varsayalım. Verileri 10.0.0.3'te yaşayan 192.168.1.4 sanal makinesine gönderir. Bir ARP isteği oluşturulur ve ağ Nitro kartına gönderilir. Basitlik açısından, her iki sanal makinenin de aynı "mavi" VPC'de yaşadığını varsayıyoruz.
Harita, kaynak adresini kendi adresiyle değiştirir ve ARP çerçevesini haritalama hizmetine iletir.
Haritalama hizmeti, L2 fiziksel ağı üzerinden iletim için gerekli olan bilgileri döndürür.
ARP yanıtındaki Nitro kartı, fiziksel ağdaki MAC'i VPC'deki bir adresle değiştirir.
Verileri aktarırken mantıksal MAC ve IP'yi bir VPC sarmalayıcıya sarıyoruz. Tüm bunları uygun kaynak ve hedef IP Nitro kartlarını kullanarak fiziksel ağ üzerinden aktarıyoruz.
Kontrolü paketin gönderildiği fiziksel makine gerçekleştirir. Adres sahteciliği olasılığını önlemek için bu gereklidir. Makine, haritalama servisine özel bir istek göndererek şunu sorar: “192.168.0.3 numaralı fiziksel makineden, mavi VPC'de 10.0.0.3'e yönelik bir paket aldım. O meşru mu?
Eşleme hizmeti, kaynak tahsis tablosunu kontrol eder ve paketin geçmesine izin verir veya vermez. Tüm yeni örneklerde, Nitro kartlarına ek doğrulama eklenmiştir. Teorik olarak bile onu atlamak imkansızdır. Bu nedenle, başka bir VPC'deki kaynaklara yönelik adres sahteciliği yapmak işe yaramayacaktır.
Daha sonra veriler, amaçlandığı sanal makineye gönderilir.
Eşleme hizmeti aynı zamanda farklı alt ağlardaki sanal makineler arasında veri aktarımı için mantıksal bir yönlendirici olarak da çalışır. Her şey kavramsal olarak basit, ayrıntıya girmeyeceğim.
Her paketi iletirken sunucuların haritalama servisine yöneldiği ortaya çıktı. Kaçınılmaz gecikmelerle nasıl başa çıkılır? Önbelleğe almakElbette
Güzelliği, devasa tablonun tamamını önbelleğe almanıza gerek olmamasıdır. Fiziksel bir sunucu, nispeten az sayıda VPC'den gelen sanal makineleri barındırır. Yalnızca bu VPC'lerle ilgili bilgileri önbelleğe almanız gerekir. Verilerin "varsayılan" yapılandırmada diğer VPC'lere aktarılması hâlâ yasal değildir. VPC eşleme gibi işlevler kullanılıyorsa ilgili VPC'lere ilişkin bilgiler ek olarak önbelleğe yüklenir.
Verilerin VPC'ye aktarımını çözdük.
Blackfoot
Trafiğin dışarıya, örneğin internete veya VPN aracılığıyla yere iletilmesi gerektiğinde ne yapılmalı? Bize burada yardım ediyor Blackfoot — AWS dahili hizmeti. Güney Afrika ekibimiz tarafından geliştirilmiştir. Bu nedenle hizmete Güney Afrika'da yaşayan bir penguen adı verilmiştir.
Blackfoot trafiği ayrıştırır ve onunla gerekeni yapar. Veriler internete olduğu gibi gönderilir.
Bir VPN kullanıldığında veriler IPsec'te kapsülden çıkarılır ve yeniden sarılır.
Direct Connect kullanıldığında trafik etiketlenir ve uygun VLAN'a gönderilir.
HiperDüzlem
Bu bir dahili akış kontrol hizmetidir. Birçok ağ hizmeti izleme gerektirir veri akışı durumları. Örneğin, NAT kullanırken akış kontrolü her IP:hedef bağlantı noktası çiftinin benzersiz bir giden bağlantı noktasına sahip olmasını sağlamalıdır. Dengeleyici durumunda NLB - Ağ Yük Dengeleyiciveri akışının her zaman aynı hedef sanal makineye yönlendirilmesi gerekir. Güvenlik Grupları durum bilgisi olan bir güvenlik duvarıdır. Gelen trafiği izler ve giden paket akışı için dolaylı olarak bağlantı noktalarını açar.
AWS bulutunda iletim gecikme gereksinimleri son derece yüksektir. Bu yüzden HiperDüzlem tüm ağın performansı açısından kritik öneme sahiptir.
Hyperplane, EC2 sanal makineleri üzerine kurulmuştur. Burada sihir yok, sadece kurnazlık var. İşin püf noktası, bunların büyük RAM'e sahip sanal makineler olmasıdır. İşlemler işlemseldir ve yalnızca bellekte gerçekleştirilir. Bu, yalnızca onlarca mikrosaniyelik gecikmelere ulaşmanıza olanak tanır. Diskle çalışmak tüm üretkenliği öldürür.
Hyperplane, bu tür çok sayıda EC2 makinesinden oluşan dağıtılmış bir sistemdir. Her sanal makinenin bant genişliği 5 GB/s'dir. Bu, bölgesel ağın tamamında inanılmaz terabit bant genişliği sağlar ve işleme olanak tanır saniyede milyonlarca bağlantı.
HyperPlane yalnızca akışlarla çalışır. VPC paket kapsüllemesi bunun için tamamen şeffaftır. Bu dahili hizmetteki olası bir güvenlik açığı yine de VPC izolasyonunun kırılmasını engelleyecektir. Aşağıdaki seviyeler güvenlikten sorumludur.
Gürültülü komşu
Hala bir sorun var gürültücü komşu - gürültülü komşu. 8 düğümümüz olduğunu varsayalım. Bu düğümler tüm bulut kullanıcılarının akışlarını işler. Her şey yolunda görünüyor ve yükün tüm düğümlere eşit olarak dağıtılması gerekiyor. Düğümler çok güçlüdür ve onları aşırı yüklemek zordur.
Ancak mimarimizi beklenmedik senaryolara göre inşa ediyoruz.
Düşük olasılık imkansız anlamına gelmez.
Bir veya daha fazla kullanıcının çok fazla yük oluşturacağı bir durumu hayal edebiliriz. Tüm HyperPlane düğümleri bu yükün işlenmesine dahil olur ve diğer kullanıcılar potansiyel olarak bir tür performans düşüşü yaşayabilir. Bu, kiracıların birbirlerini etkileme yeteneğinin olmadığı bulut kavramını bozuyor.
Gürültülü bir komşu sorunu nasıl çözülür? Akla gelen ilk şey parçalamadır. 8 düğümümüz mantıksal olarak her biri 4 düğümden oluşan 2 parçaya bölünmüştür. Artık gürültülü bir komşu tüm kullanıcıların yalnızca dörtte birini rahatsız edecek, ancak onları büyük ölçüde rahatsız edecek.
İşleri farklı yapalım. Her kullanıcıya yalnızca 3 düğüm tahsis edeceğiz.
İşin püf noktası, düğümleri farklı kullanıcılara rastgele atamaktır. Aşağıdaki resimde mavi kullanıcı, diğer iki kullanıcıdan (yeşil ve turuncu) biriyle düğümleri kesiştiriyor.
8 düğüm ve 3 kullanıcıyla gürültülü bir komşunun kullanıcılardan biriyle kesişme olasılığı %54'tür. Mavi bir kullanıcının diğer kiracıları etkileme olasılığı da budur. Aynı zamanda yükünün sadece bir kısmı. Örneğimizde, bu etki en azından bir şekilde herkes tarafından değil, tüm kullanıcıların yalnızca üçte biri tarafından fark edilecektir. Bu zaten iyi bir sonuç.
Kesişecek kullanıcı sayısı
Yüzde olarak olasılık
0
%18
1
%54
2
%26
3
2%
Durumu gerçeğe yaklaştıralım - 100 düğümü ve 5 düğümde 5 kullanıcıyı ele alalım. Bu durumda hiçbir düğüm %77 olasılıkla kesişmeyecektir.
Kesişecek kullanıcı sayısı
Yüzde olarak olasılık
0
%77
1
%21
2
%1,8
3
%0,06
4
%0,0006
5
%0,00000013
Çok sayıda HyperPlane düğümü ve kullanıcısının olduğu gerçek bir durumda, gürültülü bir komşunun diğer kullanıcılar üzerindeki potansiyel etkisi minimum düzeydedir. Bu yöntem denir karıştırma - karışık parçalama. Düğüm arızasının olumsuz etkisini en aza indirir.
Pek çok hizmet HyperPlane temel alınarak oluşturulmuştur: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Ağ ölçeği
Şimdi ağın ölçeği hakkında konuşalım. Ekim 2019 için AWS hizmetlerini şu bölgelerde sunuyor: 22 bölgeve 9 tane daha planlanıyor.
- Her bölge birden fazla Erişilebilirlik Alanı içerir. Dünya çapında 69 tane var.
- Her AZ, Veri İşleme Merkezlerinden oluşur. Toplamda 8'den fazla yok.
- Veri merkezi, bazıları 300'e kadar olan çok sayıda sunucuya ev sahipliği yapar.
Şimdi tüm bunların ortalamasını alalım, çarpalım ve yansıtan etkileyici bir rakam elde edelim. Amazon bulut ölçeği.
Erişilebilirlik Alanları ile veri merkezi arasında birçok optik bağlantı vardır. En büyük bölgelerimizden birinde sadece kendi aralarında A'dan Z'ye iletişim ve diğer bölgelerle iletişim merkezleri (Transit Merkezleri) için 388 kanal döşendi. Toplamda bu çılgınlık veriyor 5000 Tbit.
Backbone AWS, bulut için özel olarak oluşturulmuş ve optimize edilmiştir. Bunu kanallar üzerinde inşa ediyoruz 100 GB/sn. Çin'deki bölgeler hariç, onları tamamen kontrol ediyoruz. Trafik diğer şirketlerin yükleriyle paylaşılmıyor.
Elbette özel omurga ağına sahip tek bulut sağlayıcısı biz değiliz. Giderek daha fazla büyük şirket bu yolu izliyor. Bu, örneğin bağımsız araştırmacılar tarafından onaylanmıştır. .
Grafik, içerik sağlayıcıların ve bulut sağlayıcıların payının arttığını gösteriyor. Bu nedenle omurga sağlayıcıların internet trafiğindeki payı sürekli azalmaktadır.
Bunun neden olduğunu açıklayacağım. Daha önce çoğu web hizmetine doğrudan İnternet üzerinden erişilebiliyor ve kullanılabiliyordu. Günümüzde giderek daha fazla sayıda sunucu bulutta yer alıyor ve bunlara üzerinden erişilebiliyor. CDN - İçerik Dağıtım Ağı. Bir kaynağa erişmek için kullanıcı İnternet üzerinden yalnızca en yakın CDN PoP'a gider - Varlık Noktası. Çoğu zaman yakınlarda bir yerdedir. Daha sonra halka açık interneti terk ediyor ve örneğin Atlantik boyunca özel bir omurga üzerinden uçarak doğrudan kaynağa ulaşıyor.
Acaba bu trend devam ederse internet 10 yıl içinde nasıl değişecek?
Fiziksel kanallar
Bilim adamları henüz Evrendeki ışığın hızının nasıl artırılacağını çözemediler, ancak onu optik fiber yoluyla iletme yöntemlerinde büyük ilerleme kaydettiler. Şu anda 6912 fiber kablo kullanıyoruz. Bu, kurulum maliyetlerini önemli ölçüde optimize etmeye yardımcı olur.
Bazı bölgelerde özel kablolar kullanmak zorunda kalıyoruz. Örneğin Sidney bölgesinde termitlere karşı özel kaplamalı kablolar kullanıyoruz.
Hiç kimse sorunlardan muaf değildir ve bazen kanallarımız zarar görebilir. Sağdaki fotoğraf Amerika'nın bir bölgesinde inşaat işçileri tarafından yırtılan optik kabloları gösteriyor. Kaza sonucunda sadece 13 veri paketinin kaybolması şaşırtıcıydı. Bir kez daha - sadece 13! Sistem tam anlamıyla anında yedek kanallara geçti - ölçek çalışıyor.
Amazon'un bazı bulut hizmetleri ve teknolojilerini dörtnala inceledik. Umarım mühendislerimizin çözmesi gereken görevlerin ölçeği hakkında en azından bir fikriniz vardır. Kişisel olarak bunu çok heyecan verici buluyorum.
Bu, Vasily Pantyukhin'in AWS cihazıyla ilgili üçlemesinin son kısmı. İÇİNDE kısımlar sunucu optimizasyonunu ve veritabanı ölçeklendirmesini açıklar ve — sunucusuz işlevler ve Havai Fişek.
Üzerinde Kasım ayında Vasily Pantyukhin Amazon cihazının yeni ayrıntılarını paylaşacak. O Arızaların nedenleri ve Amazon'daki dağıtılmış sistemlerin tasarımı hakkında. 24 Ekim hâlâ mümkün İyi bir fiyata bilet alın ve daha sonra ödeyin. HighLoad++'a bekliyoruz, gelin sohbet edelim!
Kaynak: habr.com