Amazon Web Services şəbəkəsinin miqyası dünya üzrə 69 regionda 22 zonadır: ABŞ, Avropa, Asiya, Afrika və Avstraliya. Hər zonada 8-ə qədər məlumat mərkəzi var - Məlumat Emalı Mərkəzləri. Hər bir məlumat mərkəzində minlərlə və ya yüz minlərlə server var. Şəbəkə elə qurulub ki, bütün mümkün olmayan kəsilmə ssenariləri nəzərə alınsın. Məsələn, bütün bölgələr bir-birindən təcrid olunub və əlçatanlıq zonaları bir neçə kilometr məsafədə ayrılıb. Kabeli kəssəniz belə, sistem ehtiyat kanallara keçəcək və məlumat itkisi bir neçə məlumat paketini təşkil edəcək. Vasili Pantyuxin şəbəkənin başqa hansı prinsiplər üzərində qurulduğu və necə qurulduğu barədə danışacaq.
Vasili Pantyuxin .ru şirkətlərində Unix administratoru kimi başlamış, 6 il böyük Sun Microsystem aparatları üzərində çalışmış və EMC-də 11 il ərzində məlumat mərkəzli dünyanı təbliğ etmişdir. O, təbii olaraq özəl buludlara çevrildi, sonra ictimai buludlara keçdi. İndi Amazon Web Services memarı kimi o, AWS buludunda yaşamağa və inkişaf etməyə kömək etmək üçün texniki məsləhətlər verir.
AWS trilogiyasının əvvəlki hissəsində Vasili fiziki serverlərin dizaynını və verilənlər bazası miqyasını araşdırdı. Nitro kartları, xüsusi KVM əsaslı hipervizor, Amazon Aurora verilənlər bazası - bütün bunlar haqqında materialda "" Kontekst üçün oxuyun və ya baxın çıxışlar.
Bu hissə AWS-də ən mürəkkəb sistemlərdən biri olan şəbəkə miqyasına diqqət yetirəcəkdir. Düz şəbəkədən Virtual Şəxsi Bulud və onun dizaynına qədər təkamül, Blackfoot və HyperPlane-in daxili xidmətləri, səs-küylü qonşu problemi və sonda - şəbəkənin miqyası, magistral və fiziki kabellər. Bütün bunlar haqqında kəsik altında.
İmtina: aşağıda göstərilən hər şey Vasilinin şəxsi fikridir və Amazon Veb Xidmətlərinin mövqeyi ilə üst-üstə düşməyə bilər.
Şəbəkə miqyası
AWS bulud 2006-cı ildə istifadəyə verildi. Onun şəbəkəsi kifayət qədər primitiv idi - düz bir quruluşla. Şəxsi ünvanların çeşidi bütün bulud icarəçiləri üçün ümumi idi. Yeni virtual maşın işə saldığınız zaman təsadüfən bu diapazondan mövcud IP ünvanı aldınız.
Bu yanaşmanı həyata keçirmək asan idi, lakin buluddan istifadəni əsaslı şəkildə məhdudlaşdırırdı. Xüsusilə, yerdə və AWS-də özəl şəbəkələri birləşdirən hibrid həllər hazırlamaq olduqca çətin idi. Ən ümumi problem IP ünvan diapazonlarının üst-üstə düşməsi idi.
Virtual Şəxsi Bulud
Buludun tələbat olduğu ortaya çıxdı. Ölçeklenebilirlik və ondan on milyonlarla kirayəçi tərəfindən istifadə imkanları haqqında düşünməyin vaxtı gəldi. Düz şəbəkə əsas maneəyə çevrilib. Buna görə də, istifadəçiləri şəbəkə səviyyəsində bir-birindən necə təcrid etmək barədə düşündük ki, onlar IP diapazonlarını müstəqil seçə bilsinlər.
Şəbəkə izolyasiyası dedikdə ağlınıza gələn ilk şey nədir? Əlbəttə VLAN и VRF - Virtual marşrutlaşdırma və yönləndirmə.
Təəssüf ki, alınmadı. VLAN ID cəmi 12 bitdir ki, bu da bizə yalnız 4096 təcrid olunmuş seqment verir. Hətta ən böyük açarlar da maksimum 1-2 min VRF-dən istifadə edə bilər. VRF və VLAN-ın birlikdə istifadəsi bizə yalnız bir neçə milyon alt şəbəkə verir. Bu, hər biri birdən çox alt şəbəkədən istifadə etməyi bacarmalı olan on milyonlarla kirayəçi üçün mütləq kifayət deyil.
Biz həmçinin tələb olunan sayda böyük qutuları, məsələn, Cisco və ya Juniper-dən ala bilmirik. İki səbəb var: bu çox bahadır və biz onların inkişafı və yamaq siyasətlərinin mərhəmətinə düşmək istəmirik.
Yalnız bir nəticə var - öz həllinizi edin.
2009-cu ildə elan etdik VPC - Virtual Şəxsi Bulud. Ad ilişib və indi bir çox bulud provayderi də ondan istifadə edir.
VPC virtual şəbəkədir SDN (Proqram təminatı ilə müəyyən edilmiş şəbəkə). L2 və L3 səviyyələrində xüsusi protokollar icad etməməyə qərar verdik. Şəbəkə standart Ethernet və IP üzərində işləyir. Şəbəkə üzərindən ötürmə üçün virtual maşın trafiki öz protokol paketimizə daxil edilir. Bu, kirayəçinin VPC-yə aid olan şəxsiyyət vəsiqəsini göstərir.
Sadə səslənir. Bununla belə, aradan qaldırılmalı olan bir sıra ciddi texniki problemlər var. Məsələn, virtual MAC/IP ünvanlarının, VPC ID-nin və müvafiq fiziki MAC/IP-nin xəritələşdirilməsində məlumatların harada və necə saxlanması. AWS miqyasında bu, minimal giriş gecikmələri ilə işləməli olan böyük bir cədvəldir. Bunun üçün cavabdehdir Xəritəçəkmə xidməti, bütün şəbəkə boyunca nazik bir təbəqədə yayılmışdır.
Yeni nəsil maşınlarda kapsullaşdırma aparat səviyyəsində Nitro kartları tərəfindən həyata keçirilir. Köhnə hallarda, inkapsulyasiya və dekapsulyasiya proqrama əsaslanır.
Ümumi mənada bunun necə işlədiyini anlayaq. L2 səviyyəsindən başlayaq. Tutaq ki, 10.0.0.2 fiziki serverdə IP 192.168.0.3 olan virtual maşınımız var. O, məlumatları 10.0.0.3-də yaşayan 192.168.1.4 virtual maşına göndərir. ARP sorğusu yaradılır və şəbəkə Nitro kartına göndərilir. Sadəlik üçün hər iki virtual maşının eyni “mavi” VPC-də yaşadığını güman edirik.
Xəritə mənbə ünvanını özününki ilə əvəz edir və ARP çərçivəsini xəritəçəkmə xidmətinə yönləndirir.
Xəritəçəkmə xidməti L2 fiziki şəbəkəsi üzərindən ötürülməsi üçün lazım olan məlumatları qaytarır.
ARP cavabında Nitro kartı fiziki şəbəkədəki MAC-ı VPC-dəki ünvanla əvəz edir.
Məlumatları ötürərkən məntiqi MAC və IP-ni VPC paketinə yığırıq. Biz bütün bunları müvafiq mənbə və təyinat IP Nitro kartlarından istifadə edərək fiziki şəbəkə üzərindən ötürürük.
Yoxlamanı paketin təyin olunduğu fiziki maşın həyata keçirir. Bu, ünvan saxtakarlığı ehtimalının qarşısını almaq üçün lazımdır. Maşın xəritəçəkmə xidmətinə xüsusi sorğu göndərir və soruşur: “192.168.0.3 fiziki maşından mavi VPC-də 10.0.0.3 üçün nəzərdə tutulmuş paket aldım. O qanunidirmi?
Xəritəçəkmə xidməti resurs bölgüsü cədvəlini yoxlayır və paketin keçməsinə icazə verir və ya rədd edir. Bütün yeni hallarda əlavə yoxlama Nitro kartlarına daxil edilmişdir. Hətta nəzəri cəhətdən də ondan yan keçmək mümkün deyil. Buna görə də, başqa VPC-də resursların saxtalaşdırılması işləməyəcək.
Daha sonra məlumatlar nəzərdə tutulduğu virtual maşına göndərilir.
Xəritəçəkmə xidməti həmçinin müxtəlif alt şəbəkələrdə virtual maşınlar arasında məlumatların ötürülməsi üçün məntiqi marşrutlaşdırıcı kimi işləyir. Konseptual olaraq hər şey sadədir, təfərrüata varmayacağam.
Belə çıxır ki, hər bir paketi ötürərkən serverlər xəritələşdirmə xidmətinə müraciət edirlər. Qaçılmaz gecikmələrlə necə məşğul olmaq olar? Keşləmə, əlbəttə.
Gözəlliyi ondadır ki, bütün nəhəng masanı yaddaşda saxlamağa ehtiyac yoxdur. Fiziki server nisbətən az sayda VPC-dən virtual maşınlara ev sahibliyi edir. Siz yalnız bu VPC-lər haqqında məlumatı keşləməlisiniz. “Defolt” konfiqurasiyada məlumatların digər VPC-lərə ötürülməsi hələ də qanuni deyil. VPC-peering kimi funksionallıqdan istifadə edilərsə, müvafiq VPC-lər haqqında məlumat əlavə olaraq keş yaddaşa yüklənir.
Məlumatların VPC-yə ötürülməsini sıraladıq.
Blackfoot
Trafikin xaricə, məsələn İnternetə və ya VPN vasitəsilə yerə ötürülməsi lazım olduğu hallarda nə etməli? Burada bizə kömək edir Blackfoot — AWS daxili xidməti. O, Cənubi Afrika komandamız tərəfindən hazırlanmışdır. Bu səbəbdən xidmət Cənubi Afrikada yaşayan pinqvinin adını daşıyır.
Blackfoot trafiki dekapsullaşdırır və onunla lazım olanı edir. Məlumat olduğu kimi İnternetə göndərilir.
VPN istifadə edərkən məlumatlar dekapsullaşdırılır və IPsec-ə yenidən bükülür.
Direct Connect istifadə edərkən trafik etiketlənir və müvafiq VLAN-a göndərilir.
HyperPlane
Bu daxili axına nəzarət xidmətidir. Bir çox şəbəkə xidmətləri monitorinq tələb edir məlumat axını vəziyyətləri. Məsələn, NAT istifadə edərkən, axın nəzarəti hər bir IP: təyinat port cütlüyünün unikal çıxış portuna malik olmasını təmin etməlidir. Balanslaşdırıcı vəziyyətində NLB - Şəbəkə yük balanslaşdırıcısı, məlumat axını həmişə eyni hədəf virtual maşına yönəldilməlidir. Təhlükəsizlik Qrupları vəziyyətə uyğun təhlükəsizlik divarıdır. O, daxil olan trafiki izləyir və gedən paket axını üçün dolayı portları açır.
AWS buludunda ötürmə gecikmə tələbləri olduqca yüksəkdir. Buna görə də HyperPlane bütün şəbəkənin performansı üçün vacibdir.
Hyperplane EC2 virtual maşınlarında qurulub. Burada sehr yoxdur, sadəcə hiylə var. İş ondadır ki, bunlar böyük RAM-a malik virtual maşınlardır. Əməliyyatlar əməliyyat xarakterlidir və yalnız yaddaşda yerinə yetirilir. Bu, yalnız onlarla mikrosaniyəlik gecikmələrə nail olmağa imkan verir. Disklə işləmək bütün məhsuldarlığı məhv edərdi.
Hyperplane çox sayda belə EC2 maşınlarının paylanmış sistemidir. Hər bir virtual maşın 5 GB/s ötürmə qabiliyyətinə malikdir. Bütün regional şəbəkədə bu, inanılmaz terabit bant genişliyi təmin edir və emal etməyə imkan verir saniyədə milyonlarla əlaqə.
HyperPlane yalnız axınlarla işləyir. VPC paket inkapsulyasiyası bunun üçün tamamilə şəffafdır. Bu daxili xidmətdə potensial zəiflik hələ də VPC izolyasiyasının pozulmasının qarşısını alacaq. Aşağıdakı səviyyələr təhlükəsizlik üçün cavabdehdir.
Səs-küylü qonşu
Hələ problem var səs-küylü qonşu - səs-küylü qonşu. Tutaq ki, bizdə 8 qovşaq var. Bu qovşaqlar bütün bulud istifadəçilərinin axınlarını emal edir. Hər şey yaxşı görünür və yük bütün qovşaqlarda bərabər paylanmalıdır. Düyünlər çox güclüdür və onları həddən artıq yükləmək çətindir.
Amma biz arxitekturamızı hətta mümkün olmayan ssenarilər əsasında qururuq.
Aşağı ehtimal qeyri-mümkün demək deyil.
Bir və ya daha çox istifadəçinin çox yük yarada biləcəyi bir vəziyyəti təsəvvür edə bilərik. Bütün HyperPlane qovşaqları bu yükün emalında iştirak edir və digər istifadəçilər potensial olaraq bir növ performans zərbəsi ilə üzləşə bilər. Bu, kirayəçilərin bir-birinə təsir etmək imkanı olmayan bulud anlayışını pozur.
Səs-küylü qonşunun problemini necə həll etmək olar? Ağla gələn ilk şey parçalamaqdır. 8 qovşağımız məntiqi olaraq hər biri 4 qovşaqdan ibarət 2 parçaya bölünür. İndi səs-küylü bir qonşu bütün istifadəçilərin yalnız dörddə birini narahat edəcək, lakin onları çox narahat edəcək.
Gəlin hər şeyi fərqli edək. Hər istifadəçiyə yalnız 3 qovşaq ayıracağıq.
Hiylə müxtəlif istifadəçilərə qovşaqları təsadüfi təyin etməkdir. Aşağıdakı şəkildə mavi istifadəçi digər iki istifadəçidən biri ilə - yaşıl və narıncı ilə qovşaqları kəsir.
8 qovşaq və 3 istifadəçi ilə səs-küylü qonşunun istifadəçilərdən biri ilə kəsişməsi ehtimalı 54% -dir. Məhz bu ehtimalla mavi istifadəçi digər kirayəçilərə təsir edəcək. Eyni zamanda, onun yükünün yalnız bir hissəsi. Bizim nümunəmizdə bu təsir ən azı hər kəs üçün deyil, bütün istifadəçilərin yalnız üçdə birinə nəzərə çarpacaq. Bu, artıq yaxşı nəticədir.
Kesişəcək istifadəçilərin sayı
Ehtimal faizlə
0
18%
1
54%
2
26%
3
2%
Vəziyyəti reallığa yaxınlaşdıraq - 100 qovşaq və 5 qovşaqda 5 istifadəçi götürək. Bu halda qovşaqların heç biri 77% ehtimalla kəsişməyəcək.
Kesişəcək istifadəçilərin sayı
Ehtimal faizlə
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Həqiqi vəziyyətdə, çox sayda HyperPlane qovşaqları və istifadəçiləri ilə səs-küylü qonşunun digər istifadəçilərə potensial təsiri minimaldır. Bu üsul adlanır qarışdırma parçalanması - qarışdırmaq. Düyün çatışmazlığının mənfi təsirini minimuma endirir.
Bir çox xidmətlər HyperPlane əsasında qurulur: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Şəbəkə miqyası
İndi şəbəkənin özünün miqyasından danışaq. 2019-cu ilin oktyabr ayı üçün AWS öz xidmətlərini təklif edir 22 rayon, daha 9-u planlaşdırılıb.
- Hər bölgədə bir neçə Əlçatımlılıq Zonası var. Dünyada onlardan 69-u var.
- Hər bir AZ Məlumat Emalı Mərkəzlərindən ibarətdir. Onların cəmi 8-dən çoxu yoxdur.
- Məlumat mərkəzində çoxlu sayda server var, bəziləri 300-ə qədərdir.
İndi bütün bunları orta hesabla götürək, çoxaldaq və əks etdirən təsirli bir rəqəm əldə edək Amazon bulud şkalası.
Əlçatanlıq Zonaları və məlumat mərkəzi arasında çoxlu optik əlaqələr var. Ən böyük rayonlarımızdan birində yalnız AZ-ın bir-biri ilə əlaqəsi və digər bölgələrlə rabitə mərkəzləri (Tranzit Mərkəzləri) üçün 388 kanal çəkilib. Ümumilikdə bu dəlilik verir 5000 Tbit.
Backbone AWS xüsusi olaraq bulud üçün qurulmuş və optimallaşdırılmışdır. Biz onu kanallar üzərində qururuq 100 GB / s. Çindəki bölgələr istisna olmaqla, onlara tamamilə nəzarət edirik. Trafik digər şirkətlərin yükləri ilə paylaşılmır.
Əlbəttə ki, biz özəl magistral şəbəkəsi olan yeganə bulud provayderi deyilik. Getdikcə daha çox böyük şirkətlər bu yolla gedirlər. Bu, məsələn, müstəqil tədqiqatçılar tərəfindən təsdiqlənir .
Qrafik göstərir ki, məzmun provayderləri və bulud provayderlərinin payı artır. Bu səbəbdən magistral provayderlərin internet trafikinin payı daim azalır.
Bunun niyə baş verdiyini izah edəcəyəm. Əvvəllər əksər veb-xidmətlər əlçatan idi və birbaşa İnternetdən istifadə olunurdu. Hal-hazırda, getdikcə daha çox server buludda yerləşir və onlar vasitəsilə əldə edilə bilər CDN - Məzmun paylama şəbəkəsi. Mənbəyə daxil olmaq üçün istifadəçi İnternet vasitəsilə yalnız ən yaxın CDN PoP-ə keçir - Mövcudluq nöqtəsi. Çox vaxt yaxınlıqda yerləşir. Sonra o, ictimai interneti tərk edir və məsələn, Atlantik okeanı boyunca şəxsi magistral vasitəsilə uçur və birbaşa resursa daxil olur.
Maraqlıdır, bu tendensiya davam edərsə, internet 10 ildən sonra necə dəyişəcək?
Fiziki kanallar
Elm adamları hələ Kainatda işığın sürətini necə artıracağını başa düşməyiblər, lakin optik lif vasitəsilə onun ötürülməsi üsullarında böyük irəliləyiş əldə ediblər. Hazırda 6912 fiber kabeldən istifadə edirik. Bu, onların quraşdırılması xərclərini əhəmiyyətli dərəcədə optimallaşdırmağa kömək edir.
Bəzi bölgələrdə xüsusi kabellərdən istifadə etməli oluruq. Məsələn, Sidney bölgəsində termitlərə qarşı xüsusi örtüklü kabellərdən istifadə edirik.
Heç kim bəlalardan qorunmur və bəzən kanallarımız zədələnir. Sağdakı fotoda Amerika bölgələrindən birində tikinti işçiləri tərəfindən cırılan optik kabellər göstərilir. Qəza nəticəsində cəmi 13 məlumat paketi itirilib ki, bu da təəccüb doğurur. Bir daha - cəmi 13! Sistem sözün əsl mənasında ehtiyat kanallara keçdi - tərəzi işləyir.
Biz Amazon-un bəzi bulud xidmətləri və texnologiyalarından istifadə etdik. Ümid edirəm ki, mühəndislərimizin həll etməli olduğu vəzifələrin miqyası haqqında heç olmasa bir fikriniz var. Şəxsən mən bunu çox həyəcanlı hesab edirəm.
Bu, Vasili Pantyuxinin AWS cihazı haqqında trilogiyasının yekun hissəsidir. IN hissələr server optimallaşdırılması və verilənlər bazası miqyasını təsvir edir və — serversiz funksiyalar və Firecracker.
Haqqında noyabrda Vasili Pantyuxin Amazon cihazının yeni detallarını paylaşacaq. O nasazlıqların səbəbləri və Amazon-da paylanmış sistemlərin dizaynı haqqında. 24 oktyabr hələ də mümkündür yaxşı qiymətə bilet və sonra ödəyin. Sizi HighLoad++-da gözləyirik, gəlin söhbət edək!
Mənbə: www.habr.com