Skala jaringan Layanan Web Amazon yaiku 69 zona ing saindenging jagad ing 22 wilayah: AS, Eropa, Asia, Afrika lan Australia. Saben zona ngemot nganti 8 pusat data - Pusat Pangolahan Data. Saben pusat data duwe ewonan utawa atusan ewu server. Jaringan kasebut dirancang kanthi cara supaya kabeh skenario pemadaman sing ora bisa ditindakake. Contone, kabeh wilayah diisolasi saka saben liyane, lan zona aksesibilitas dipisahake kanthi jarak sawetara kilometer. Malah yen sampeyan Cut kabel, sistem bakal ngalih menyang saluran serep, lan mundhut informasi bakal jumlah kanggo sawetara paket data. Vasily Pantyukhin bakal pirembagan bab apa prinsip liyane jaringan dibangun lan carane iku wis kabentuk.
Vasily Pantyukhin miwiti minangka administrator Unix ing perusahaan .ru, makarya ing hardware Sun Microsystem gedhe kanggo 6 taun, lan martakakΓ© donya data-sentris kanggo 11 taun ing EMC. Secara alami berkembang dadi awan pribadi, banjur pindhah menyang awan umum. Saiki, minangka arsitek Layanan Web Amazon, dheweke menehi saran teknis kanggo mbantu urip lan berkembang ing awan AWS.
Ing bagean sadurunge trilogi AWS, Vasily nliti desain server fisik lan skala database. Kertu Nitro, hypervisor basis KVM khusus, database Amazon Aurora - babagan kabeh iki ing materi "" Waca konteks utawa nonton pidato.
Bagian iki bakal fokus ing skala jaringan, salah sawijining sistem paling kompleks ing AWS. Γvolusi saka jaringan warata menyang Virtual Private Cloud lan desaine, layanan internal Blackfoot lan HyperPlane, masalah tetanggan rame, lan ing pungkasan - ukuran jaringan, backbone lan kabel fisik. Babagan kabeh iki ing ngisor potong.
Penafian: kabeh ing ngisor iki minangka pendapat pribadi Vasily lan bisa uga ora cocog karo posisi Layanan Web Amazon.
Skala jaringan
AWS awan diluncurake ing taun 2006. Jaringane cukup primitif - kanthi struktur sing rata. Kisaran alamat pribadi umum kanggo kabeh panyewa awan. Nalika miwiti mesin virtual anyar, sampeyan ora sengaja nampa alamat IP sing kasedhiya saka sawetara iki.
Pendekatan iki gampang dileksanakake, nanging dhasar mbatesi panggunaan awan. Utamane, cukup angel ngembangake solusi hibrida sing nggabungake jaringan pribadi ing lemah lan ing AWS. Masalah sing paling umum yaiku tumpang tindih kisaran alamat IP.
Awan Pribadi Virtual
Mendhung pranyata dikarepake. Wektu wis teka kanggo mikir babagan skalabilitas lan kemungkinan panggunaane dening puluhan yuta panyewan. Jaringan datar wis dadi alangan utama. Mulane, kita mikir babagan carane ngisolasi pangguna saka saben liyane ing tingkat jaringan supaya bisa milih kisaran IP kanthi mandiri.
Apa sing pertama dipikirake nalika sampeyan mikir babagan pamisahan jaringan? Mesthi wae VLAN ΠΈ VRF - Virtual Routing lan Terusake.
Sayange, ora bisa. VLAN ID mung 12 bit, kang menehi kita mung 4096 perangan terisolasi. Malah saklar paling gedhe bisa nggunakake maksimal 1-2 ewu VRF. Nggunakake VRF lan VLAN bebarengan menehi kita mung sawetara yuta subnets. Iki mesthi ora cukup kanggo puluhan yuta panyewan, sing saben-saben kudu bisa nggunakake pirang-pirang subnet.
Kita uga ora bisa tuku jumlah kothak gedhe sing dibutuhake, contone, saka Cisco utawa Juniper. Ana rong sebab: larang regane, lan kita ora pengin dadi kawicaksanan pembangunan lan patching.
Mung ana siji kesimpulan - nggawe solusi dhewe.
Ing 2009 kita ngumumake VPC - Awan Pribadi Virtual. Jeneng kasebut macet lan saiki akeh panyedhiya awan uga nggunakake.
VPC minangka jaringan virtual SDN (Software Defined Network). Kita mutusake ora nggawe protokol khusus ing tingkat L2 lan L3. Jaringan kasebut nganggo Ethernet lan IP standar. Kanggo transmisi liwat jaringan, lalu lintas mesin virtual dienkapsulasi ing bungkus protokol kita dhewe. Iku nuduhake ID sing kagungane VPC tenant.
Muni prasaja. Nanging, ana sawetara tantangan teknis serius sing kudu diatasi. Contone, ngendi lan carane nyimpen data ing pemetaan virtual MAC / alamat IP, VPC ID lan cocog fisik MAC / IP. Ing skala AWS, iki minangka tabel gedhe sing kudu ditindakake kanthi wektu tundha akses minimal. Tanggung jawab iki layanan pemetaan, sing nyebar ing lapisan tipis ing saindhenging jaringan.
Ing mesin generasi anyar, enkapsulasi dileksanakake dening kertu Nitro ing tingkat hardware. Ing kasus lawas, enkapsulasi lan decapsulation adhedhasar piranti lunak.
Ayo ngerteni cara kerjane ing istilah umum. Ayo dadi miwiti karo tingkat L2. Ayo dadi nganggep yen kita duwe mesin virtual karo IP 10.0.0.2 ing server fisik 192.168.0.3. Iku ngirim data kanggo mesin virtual 10.0.0.3, kang urip ing 192.168.1.4. Panjaluk ARP digawe lan dikirim menyang kertu Nitro jaringan. Kanggo gamblang, kita nganggep yen loro mesin virtual manggon ing VPC "biru" padha.
Peta ngganti alamat sumber karo dhewe lan nerusake pigura ARP menyang layanan pemetaan.
Layanan pemetaan ngasilake informasi sing perlu kanggo transmisi liwat jaringan fisik L2.
Kertu Nitro ing respon ARP ngganti MAC ing jaringan fisik karo alamat ing VPC.
Nalika nransfer data, kita mbungkus MAC lan IP logis ing bungkus VPC. Kita ngirim kabeh iki liwat jaringan fisik nggunakake sumber lan panggonan kertu IP Nitro cocok.
Mesin fisik sing dituju paket kasebut nindakake mriksa. Iki perlu kanggo nyegah kemungkinan spoofing alamat. Mesin ngirim panjalukan khusus kanggo layanan pemetaan lan takon: "Saka mesin fisik 192.168.0.3 Aku nampa paket sing dimaksudakΓ© kanggo 10.0.0.3 ing VPC biru. Apa dheweke sah?
Layanan pemetaan mriksa tabel alokasi sumber daya lan ngidini utawa nolak paket kasebut liwat. Ing kabeh kasus anyar, validasi tambahan ditempelake ing kertu Nitro. Sampeyan ora bisa ngliwati kanthi teoritis. Mulane, spoofing menyang sumber daya ing VPC liyane ora bakal bisa.
Sabanjure, data dikirim menyang mesin virtual sing dimaksudake.
Layanan pemetaan uga dianggo minangka router logis kanggo nransfer data antarane mesin virtual ing subnet beda. Kabeh iku konsep prasaja, aku ora bakal rinci.
Pranyata nalika ngirim saben paket, server nguripake layanan pemetaan. Kepiye cara ngatasi keterlambatan sing ora bisa ditindakake? Caching, mesthi.
Kaendahane yaiku sampeyan ora perlu nyimpen kabeh meja gedhe. Server fisik dadi tuan rumah mesin virtual saka jumlah VPC sing relatif cilik. Sampeyan mung kudu nyimpen informasi cache babagan VPC iki. Transfer data menyang VPC liyane ing konfigurasi "standar" isih ora sah. Yen fungsi kayata VPC-peering digunakake, informasi babagan VPC sing cocog ditambahake menyang cache.
We diurutake metu transfer data menyang VPC.
Blackfoot
Apa sing kudu ditindakake yen lalu lintas kudu dikirim ing njaba, umpamane menyang Internet utawa liwat VPN menyang lemah? Mbantu kita metu kene Blackfoot - Layanan internal AWS. Iki dikembangake dening tim Afrika Kidul. Pramila layanan kasebut dijenengi sawise penguin sing manggon ing Afrika Kidul.
Blackfoot decapsulate lalu lintas lan nindakake apa sing dibutuhake. Data dikirim menyang Internet minangka.
Data kasebut decapsulated lan dibungkus maneh ing IPsec nalika nggunakake VPN.
Nalika nggunakake Direct Connect, lalu lintas diwenehi tag lan dikirim menyang VLAN sing cocog.
HyperPlane
Iki minangka layanan kontrol aliran internal. Akeh layanan jaringan mbutuhake pemantauan negara aliran data. Contone, nalika nggunakake NAT, kontrol aliran kudu mesthekake yen saben IP: pasangan port tujuan duwe port metu unik. Ing cilik saka balancer NLB - Network Load Balancer, aliran data kudu tansah diarahake menyang mesin virtual target padha. Security Groups minangka firewall stateful. Iku ngawasi lalu lintas mlebu lan implicitly mbukak port kanggo aliran paket metu.
Ing awan AWS, syarat latensi transmisi dhuwur banget. Mulane HyperPlane kritis kanggo kinerja kabeh jaringan.
Hyperplane dibangun ing mesin virtual EC2. Ora ana sihir ing kene, mung licik. Trick iku iki mesin virtual karo RAM gedhe. Operasi transaksional lan ditindakake sacara eksklusif ing memori. Iki ngidini sampeyan entuk wektu tundha mung puluhan mikrodetik. Nggarap disk bakal mateni kabeh produktivitas.
Hyperplane minangka sistem sing disebarake saka akeh mesin EC2 kasebut. Saben mesin virtual duwe bandwidth 5 GB / s. Ing kabeh jaringan regional, iki nyedhiyakake terabit bandwidth sing luar biasa lan ngidini pangolahan mayuta-yuta sambungan per detik.
HyperPlane mung dianggo karo stream. Enkapsulasi paket VPC pancen transparan. Kerentanan potensial ing layanan internal iki isih bakal nyegah pamisahan VPC supaya ora rusak. Tingkat ing ngisor iki tanggung jawab kanggo keamanan.
tanggane rame
Isih ana masalah tanggane rame - tanggane rame. Ayo nganggep kita duwe 8 simpul. Node iki ngolah aliran kabeh pangguna awan. Kabeh katon apik lan beban kudu disebarake kanthi rata ing kabeh simpul. Node banget kuat lan angel kanggo kakehan.
Nanging kita mbangun arsitektur adhedhasar skenario sing ora mungkin.
Kemungkinan kurang ora ateges mokal.
Kita bisa mbayangno kahanan ing ngendi siji utawa luwih pangguna bakal ngasilake beban sing akeh banget. Kabeh simpul HyperPlane melu ngolah beban iki lan pangguna liyane bisa uga ngalami sawetara hit kinerja. Iki ngilangi konsep awan, sing nyewo ora duwe kemampuan kanggo saling pengaruh.
Kepiye carane ngatasi masalah tetangga sing rame? Wangsulan: Bab ingkang pisanan nerangake atine sharding. 8 simpul kita sacara logis dipΓ©rang dadi 4 pecahan 2 simpul saben. Saiki pepadhamu sing rame bakal ngganggu mung seprapat kabeh pangguna, nanging bakal ngganggu banget.
Ayo dadi nindakake macem-macem. Kita bakal nyedhiyakake mung 3 simpul kanggo saben pangguna.
Trik kasebut kanthi acak nemtokake simpul menyang pangguna sing beda-beda. Ing gambar ing ngisor iki, pangguna biru intersects simpul karo salah siji saka rong pangguna liyane - ijo lan oranye.
Kanthi 8 simpul lan 3 pangguna, kemungkinan tetanggan sing rame nyabrang karo salah sawijining pangguna yaiku 54%. Kanthi kemungkinan iki pangguna biru bakal mengaruhi penyewa liyane. Ing wektu sing padha, mung bagean saka beban. Ing conto kita, pengaruh iki bakal katon paling ora kanggo kabeh wong, nanging mung sapratelo saka kabeh pangguna. Iki wis asil apik.
Jumlah pangguna sing bakal intersect
Probabilitas ing persen
0
18%
1
54%
2
26%
3
2%
Ayo nggawa kahanan nyedhaki kasunyatan - ayo njupuk 100 simpul lan 5 pangguna ing 5 simpul. Ing kasus iki, ora ana simpul sing bakal intersect kanthi kemungkinan 77%.
Jumlah pangguna sing bakal intersect
Probabilitas ing persen
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Ing kahanan nyata, kanthi jumlah node lan pangguna HyperPlane sing akeh, dampak potensial saka tetangga sing rame ing pangguna liyane minimal. Cara iki diarani nyampur sharding - ngacak sharding. Iki nyuda efek negatif saka kegagalan simpul.
Akeh layanan sing dibangun ing basis saka HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Skala jaringan
Saiki ayo ngomong babagan ukuran jaringan kasebut dhewe. Kanggo Oktober 2019 AWS nawakake layanan ing 22 wilayah, lan 9 liyane direncanakake.
- Saben wilayah ngemot sawetara Zona Ketersediaan. Ana 69 wong ing saindenging jagad.
- Saben AZ kasusun saka Pusat Pangolahan Data. Jumlahe ora luwih saka 8.
- Pusat data nduwe akeh server, sawetara nganti 300.
Saiki ayo rata-rata kabeh iki, multiply lan entuk tokoh sing nyengsemake sing nggambarake Skala awan Amazon.
Ana akeh pranala optik antarane Availability Zones lan pusat data. Ing salah sawijining wilayah paling gedhe, 388 saluran wis dipasang mung kanggo komunikasi AZ antarane siji liyane lan pusat komunikasi karo wilayah liyane (Pusat Transit). In total iki menehi edan 5000 Tbit.
Backbone AWS dibangun khusus kanggo lan dioptimalake kanggo awan. Kita mbangun ing saluran 100 GB / s. Kita ngontrol kabeh, kajaba wilayah ing China. Lalu lintas ora dienggo bareng karo akeh perusahaan liyane.
Mesthi, kita ora mung siji-sijine panyedhiya maya sing duwe jaringan backbone pribadi. Akeh perusahaan gedhe sing ngetutake dalan iki. Iki dikonfirmasi dening peneliti independen, contone saka .
Grafik kasebut nuduhake manawa bagean panyedhiya konten lan panyedhiya awan saya tambah akeh. Amarga iki, pangsa lalu lintas Internet saka panyedhiya backbone terus saya suda.
Aku bakal nerangake apa iki kedaden. Sadurunge, umume layanan web bisa diakses lan dikonsumsi langsung saka Internet. Saiki, luwih akeh server sing ana ing awan lan bisa diakses liwat CDN - Jaringan Distribusi Konten. Kanggo ngakses sumber daya, pangguna mung liwat Internet menyang CDN PoP sing paling cedhak - Titik Ngarsane. Paling asring ana ing ngendi wae. Banjur ninggalake Internet umum lan mabur liwat balung mburi pribadi tengen Atlantik, contone, lan langsung menyang sumber.
Aku wonder carane Internet bakal ngganti ing 10 taun yen gaya iki terus?
Saluran fisik
Para ilmuwan durung ngerti carane nambah kacepetan cahya ing Semesta, nanging wis nggawe kemajuan gedhe ing cara ngirim liwat serat optik. Saiki kita nggunakake kabel serat 6912. Iki mbantu ngoptimalake biaya instalasi kanthi signifikan.
Ing sawetara wilayah kita kudu nggunakake kabel khusus. Contone, ing wilayah Sydney kita nggunakake kabel karo lapisan khusus marang rayap.
Ora ana sing kebal saka masalah lan kadhangkala saluran kita rusak. Foto ing sisih tengen nuduhake kabel optik ing salah sawijining wilayah Amerika sing dirusak dening buruh konstruksi. Akibat saka kacilakan kasebut, mung 13 paket data sing ilang, sing nggumunake. Sepisan maneh - mung 13! Sistem kasebut langsung ngalih menyang saluran serep - ukurane bisa digunakake.
We galloped liwat sawetara layanan maya Amazon lan teknologi. Muga-muga sampeyan duwe paling ora sawetara gagasan babagan skala tugas sing kudu ditindakake para insinyur. Secara pribadi, aku nemokake iki banget nyenengake.
Iki minangka bagéan pungkasan saka trilogi Vasily Pantyukhin babagan piranti AWS. ING bagean njlèntrèhaké Optimization server lan database scaling, lan ing - fungsi tanpa server lan Firecracker.
Ing ing November Vasily Pantyukhin bakal nuduhake rincian anyar saka piranti Amazon. Dheweke babagan panyebab kegagalan lan desain sistem sing disebarake ing Amazon. 24 Oktober isih bisa tiket ing rega apik, lan mbayar mengko. Kita ngenteni sampeyan ing HighLoad++, ayo ngobrol!
Source: www.habr.com