Skala rangkaian Perkhidmatan Web Amazon ialah 69 zon di seluruh dunia di 22 wilayah: Amerika Syarikat, Eropah, Asia, Afrika dan Australia. Setiap zon mengandungi sehingga 8 pusat data - Pusat Pemprosesan Data. Setiap pusat data mempunyai ribuan atau ratusan ribu pelayan. Rangkaian direka bentuk sedemikian rupa sehingga semua senario gangguan yang tidak mungkin diambil kira. Contohnya, semua wilayah diasingkan antara satu sama lain dan zon kebolehcapaian diasingkan dalam jarak beberapa kilometer. Walaupun anda memotong kabel, sistem akan bertukar kepada saluran sandaran, dan kehilangan maklumat akan berjumlah beberapa paket data. Vasily Pantyukhin akan bercakap tentang prinsip lain rangkaian dibina dan bagaimana ia distrukturkan.
Vasily Pantyukhin bermula sebagai pentadbir Unix dalam syarikat .ru, bekerja pada perkakasan Sun Microsystem yang besar selama 6 tahun, mengkhutbahkan dunia tertumpu data di EMC selama 11 tahun. Ia secara semula jadi berkembang menjadi awan peribadi, kemudian beralih kepada awan awam. Kini, sebagai arkitek Perkhidmatan Web Amazon, dia memberikan nasihat teknikal untuk membantu hidup dan berkembang dalam awan AWS.
Dalam bahagian sebelumnya trilogi AWS, Vasily menyelidiki reka bentuk pelayan fizikal dan penskalaan pangkalan data. Kad Nitro, hipervisor berasaskan KVM tersuai, pangkalan data Amazon Aurora - tentang semua ini dalam bahan "" Baca untuk konteks atau tonton ucapan.
Bahagian ini akan menumpukan pada penskalaan rangkaian, salah satu sistem paling kompleks dalam AWS. Evolusi daripada rangkaian rata kepada Awan Persendirian Maya dan reka bentuknya, perkhidmatan dalaman Blackfoot dan HyperPlane, masalah jiran yang bising, dan pada akhirnya - skala rangkaian, tulang belakang dan kabel fizikal. Mengenai semua ini di bawah potongan.
Penafian: semua di bawah adalah pendapat peribadi Vasily dan mungkin tidak bertepatan dengan kedudukan Perkhidmatan Web Amazon.
Penskalaan rangkaian
Awan AWS telah dilancarkan pada tahun 2006. Rangkaiannya agak primitif - dengan struktur rata. Julat alamat peribadi adalah biasa kepada semua penyewa awan. Apabila memulakan mesin maya baharu, anda secara tidak sengaja menerima alamat IP yang tersedia daripada julat ini.
Pendekatan ini mudah dilaksanakan, tetapi pada asasnya mengehadkan penggunaan awan. Khususnya, agak sukar untuk membangunkan penyelesaian hibrid yang menggabungkan rangkaian persendirian di lapangan dan dalam AWS. Masalah yang paling biasa ialah pertindihan julat alamat IP.
Awan Peribadi Maya
Awan itu ternyata mendapat permintaan. Masanya telah tiba untuk memikirkan tentang kebolehskalaan dan kemungkinan penggunaannya oleh berpuluh-puluh juta penyewa. Rangkaian rata telah menjadi halangan utama. Oleh itu, kami memikirkan cara untuk mengasingkan pengguna antara satu sama lain di peringkat rangkaian supaya mereka boleh memilih julat IP secara bebas.
Apakah perkara pertama yang terlintas dalam fikiran anda apabila anda memikirkan tentang pengasingan rangkaian? Sudah tentu VLAN ΠΈ VRF - Penghalaan Maya dan Pemajuan.
Malangnya, ia tidak berjaya. ID VLAN hanya 12 bit, yang memberikan kami hanya 4096 segmen terpencil. Malah suis terbesar boleh menggunakan maksimum 1-2 ribu VRF. Menggunakan VRF dan VLAN bersama-sama memberikan kita hanya beberapa juta subnet. Ini pastinya tidak mencukupi untuk berpuluh-puluh juta penyewa, setiap satunya mesti boleh menggunakan berbilang subnet.
Kami juga tidak mampu untuk membeli bilangan kotak besar yang diperlukan, contohnya, dari Cisco atau Juniper. Terdapat dua sebab: ia mahal gila, dan kami tidak mahu bergantung pada dasar pembangunan dan penampalan mereka.
Hanya ada satu kesimpulan - buat penyelesaian anda sendiri.
Pada tahun 2009 kami mengumumkan VPC - Awan Peribadi Maya. Nama itu tersekat dan kini banyak penyedia awan juga menggunakannya.
VPC ialah rangkaian maya SDN (Rangkaian Ditakrifkan Perisian). Kami memutuskan untuk tidak mencipta protokol khas pada tahap L2 dan L3. Rangkaian berjalan pada Ethernet dan IP standard. Untuk penghantaran melalui rangkaian, trafik mesin maya dirangkumkan dalam pembalut protokol kami sendiri. Ia menunjukkan ID yang dimiliki oleh VPC penyewa.
Kedengaran mudah. Walau bagaimanapun, terdapat beberapa cabaran teknikal yang serius yang perlu diatasi. Sebagai contoh, di mana dan cara menyimpan data untuk memetakan alamat MAC/IP maya, ID VPC dan MAC/IP fizikal yang sepadan. Pada skala AWS, ini ialah jadual besar yang sepatutnya berfungsi dengan kelewatan akses yang minimum. Bertanggungjawab untuk ini perkhidmatan pemetaan, yang tersebar dalam lapisan nipis di seluruh rangkaian.
Dalam mesin generasi baharu, enkapsulasi dilakukan oleh kad Nitro pada peringkat perkakasan. Dalam keadaan lama, enkapsulasi dan penyahkapsulan adalah berasaskan perisian.
Mari kita fikirkan cara ia berfungsi secara umum. Mari kita mulakan dengan tahap L2. Mari kita anggap bahawa kita mempunyai mesin maya dengan IP 10.0.0.2 pada pelayan fizikal 192.168.0.3. Ia menghantar data ke mesin maya 10.0.0.3, yang hidup pada 192.168.1.4. Permintaan ARP dijana dan dihantar ke kad Nitro rangkaian. Untuk kesederhanaan, kami menganggap bahawa kedua-dua mesin maya hidup dalam VPC "biru" yang sama.
Peta menggantikan alamat sumber dengan alamatnya sendiri dan memajukan bingkai ARP ke perkhidmatan pemetaan.
Perkhidmatan pemetaan mengembalikan maklumat yang diperlukan untuk penghantaran melalui rangkaian fizikal L2.
Kad Nitro dalam tindak balas ARP menggantikan MAC pada rangkaian fizikal dengan alamat dalam VPC.
Apabila memindahkan data, kami membalut MAC dan IP logik dalam pembalut VPC. Kami menghantar semua ini melalui rangkaian fizikal menggunakan sumber dan kad IP Nitro destinasi yang sesuai.
Mesin fizikal yang dituju pakej melakukan semakan. Ini adalah perlu untuk mengelakkan kemungkinan penipuan alamat. Mesin menghantar permintaan khas kepada perkhidmatan pemetaan dan bertanya: βDaripada mesin fizikal 192.168.0.3 saya menerima satu paket yang bertujuan untuk 10.0.0.3 dalam VPC biru. Adakah dia sah?
Perkhidmatan pemetaan menyemak jadual peruntukan sumbernya dan membenarkan atau menafikan paket untuk dilalui. Dalam semua keadaan baharu, pengesahan tambahan dibenamkan dalam kad Nitro. Tidak mustahil untuk memintasnya walaupun secara teori. Oleh itu, penipuan kepada sumber dalam VPC lain tidak akan berfungsi.
Seterusnya, data dihantar ke mesin maya yang dimaksudkan.
Perkhidmatan pemetaan juga berfungsi sebagai penghala logik untuk memindahkan data antara mesin maya dalam subnet yang berbeza. Segala-galanya secara konsepnya mudah, saya tidak akan menjelaskan secara terperinci.
Ternyata apabila menghantar setiap paket, pelayan beralih kepada perkhidmatan pemetaan. Bagaimana untuk menangani kelewatan yang tidak dapat dielakkan? Caching, sudah tentu.
Keindahannya ialah anda tidak perlu menyimpan cache seluruh meja besar. Pelayan fizikal mengehoskan mesin maya daripada bilangan VPC yang agak kecil. Anda hanya perlu menyimpan maklumat cache tentang VPC ini. Memindahkan data ke VPC lain dalam konfigurasi "lalai" masih tidak sah. Jika fungsi seperti VPC-peering digunakan, maka maklumat tentang VPC yang sepadan juga dimuatkan ke dalam cache.
Kami menyelesaikan pemindahan data ke VPC.
Blackfoot
Apakah yang perlu dilakukan dalam kes di mana trafik perlu dihantar ke luar, contohnya ke Internet atau melalui VPN ke darat? Membantu kami di sini Blackfoot β Perkhidmatan dalaman AWS. Ia dibangunkan oleh pasukan Afrika Selatan kami. Itulah sebabnya perkhidmatan ini dinamakan sempena penguin yang tinggal di Afrika Selatan.
Blackfoot menyahkapsul lalu lintas dan melakukan apa yang diperlukan dengannya. Data dihantar ke Internet sebagaimana adanya.
Data dinyahkapsul dan dibalut semula dalam IPsec apabila menggunakan VPN.
Apabila menggunakan Sambungan Terus, trafik ditag dan dihantar ke VLAN yang sesuai.
HyperPlane
Ini ialah perkhidmatan kawalan aliran dalaman. Banyak perkhidmatan rangkaian memerlukan pemantauan keadaan aliran data. Sebagai contoh, apabila menggunakan NAT, kawalan aliran mesti memastikan bahawa setiap IP: pasangan port destinasi mempunyai port keluar yang unik. Dalam kes pengimbang NLB - Pengimbang Beban Rangkaian, aliran data hendaklah sentiasa diarahkan ke mesin maya sasaran yang sama. Kumpulan Keselamatan ialah tembok api stateful. Ia memantau trafik masuk dan secara tersirat membuka port untuk aliran paket keluar.
Dalam awan AWS, keperluan kependaman penghantaran adalah sangat tinggi. sebab tu HyperPlane kritikal kepada prestasi keseluruhan rangkaian.
Hyperplane dibina pada mesin maya EC2. Tiada sihir di sini, hanya licik. Caranya ialah ini adalah mesin maya dengan RAM yang besar. Operasi adalah transaksional dan dilakukan secara eksklusif dalam ingatan. Ini membolehkan anda mencapai kelewatan hanya berpuluh-puluh mikrosaat. Bekerja dengan cakera akan membunuh semua produktiviti.
Hyperplane ialah sistem pengedaran sejumlah besar mesin EC2 tersebut. Setiap mesin maya mempunyai lebar jalur 5 GB/s. Di seluruh rangkaian serantau, ini menyediakan terabit lebar jalur yang luar biasa dan membolehkan pemprosesan berjuta-juta sambungan sesaat.
HyperPlane hanya berfungsi dengan strim. Pengkapsulan paket VPC benar-benar telus untuknya. Potensi kelemahan dalam perkhidmatan dalaman ini masih akan menghalang pengasingan VPC daripada dipecahkan. Tahap di bawah bertanggungjawab untuk keselamatan.
jiran bising
Masih ada masalah jiran bising - jiran bising. Katakan kita mempunyai 8 nod. Nod ini memproses aliran semua pengguna awan. Segala-galanya nampaknya baik-baik saja dan beban harus diagihkan sama rata pada semua nod. Nod sangat berkuasa dan sukar untuk membebankannya.
Tetapi kami membina seni bina kami berdasarkan senario yang tidak mungkin.
Kebarangkalian rendah tidak bermakna mustahil.
Kita boleh bayangkan situasi di mana satu atau lebih pengguna akan menjana terlalu banyak beban. Semua nod HyperPlane terlibat dalam memproses beban ini dan pengguna lain berpotensi mengalami beberapa jenis prestasi prestasi. Ini memecahkan konsep awan, di mana penyewa tidak mempunyai keupayaan untuk mempengaruhi satu sama lain.
Bagaimana untuk menyelesaikan masalah jiran yang bising? Perkara pertama yang terlintas di fikiran ialah sharding. 8 nod kami secara logik dibahagikan kepada 4 serpihan 2 nod setiap satu. Kini jiran yang bising akan mengganggu hanya satu perempat daripada semua pengguna, tetapi ia akan sangat mengganggu mereka.
Mari lakukan perkara secara berbeza. Kami akan memperuntukkan hanya 3 nod kepada setiap pengguna.
Caranya ialah dengan memberikan nod secara rawak kepada pengguna yang berbeza. Dalam gambar di bawah, pengguna biru sedang bersilang nod dengan salah satu daripada dua pengguna lain - hijau dan oren.
Dengan 8 nod dan 3 pengguna, kebarangkalian jiran bising bersilang dengan salah seorang pengguna ialah 54%. Dengan kebarangkalian inilah pengguna biru akan mempengaruhi penyewa lain. Pada masa yang sama, hanya sebahagian daripada bebannya. Dalam contoh kami, pengaruh ini akan menjadi sekurang-kurangnya entah bagaimana ketara tidak kepada semua orang, tetapi kepada hanya satu pertiga daripada semua pengguna. Ini sudah keputusan yang baik.
Bilangan pengguna yang akan bersilang
Kebarangkalian dalam peratus
0
18%
1
54%
2
26%
3
2%
Mari kita dekatkan keadaan kepada realiti - mari ambil 100 nod dan 5 pengguna pada 5 nod. Dalam kes ini, tiada nod akan bersilang dengan kebarangkalian 77%.
Bilangan pengguna yang akan bersilang
Kebarangkalian dalam peratus
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Dalam situasi sebenar, dengan sejumlah besar nod dan pengguna HyperPlane, potensi kesan jiran yang bising terhadap pengguna lain adalah minimum. Kaedah ini dipanggil mencampurkan sharding - shuffle sharding. Ia meminimumkan kesan negatif kegagalan nod.
Banyak perkhidmatan dibina berdasarkan HyperPlane: Pengimbang Beban Rangkaian, Gateway NAT, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Skala rangkaian
Sekarang mari kita bercakap tentang skala rangkaian itu sendiri. Untuk Oktober 2019 AWS menawarkan perkhidmatannya di 22 wilayah, dan 9 lagi dirancang.
- Setiap wilayah mengandungi beberapa Zon Ketersediaan. Terdapat 69 daripadanya di seluruh dunia.
- Setiap AZ terdiri daripada Pusat Pemprosesan Data. Jumlahnya tidak lebih daripada 8.
- Pusat data menempatkan sejumlah besar pelayan, sesetengahnya mempunyai sehingga 300.
Sekarang mari kita ratakan semua ini, darab dan dapatkan angka yang mengagumkan yang mencerminkan Skala awan Amazon.
Terdapat banyak pautan optik antara Zon Ketersediaan dan pusat data. Di salah satu wilayah terbesar kami, 388 saluran telah disediakan hanya untuk komunikasi AZ antara satu sama lain dan pusat komunikasi dengan wilayah lain (Pusat Transit). Secara keseluruhannya ini memberi kegilaan 5000 Tbit.
Backbone AWS dibina khusus untuk dan dioptimumkan untuk awan. Kami membinanya di saluran 100 GB / s. Kami mengawalnya sepenuhnya, kecuali kawasan di China. Trafik tidak dikongsi dengan beban syarikat lain.
Sudah tentu, kami bukan satu-satunya pembekal awan dengan rangkaian tulang belakang peribadi. Semakin banyak syarikat besar mengikuti laluan ini. Ini disahkan oleh penyelidik bebas, contohnya dari .
Graf menunjukkan bahawa bahagian penyedia kandungan dan penyedia awan semakin meningkat. Disebabkan ini, bahagian trafik Internet penyedia tulang belakang sentiasa berkurangan.
Saya akan menerangkan mengapa ini berlaku. Sebelum ini, kebanyakan perkhidmatan web boleh diakses dan digunakan terus daripada Internet. Pada masa kini, semakin banyak pelayan terletak di awan dan boleh diakses melalui CDN - Rangkaian Pengedaran Kandungan. Untuk mengakses sumber, pengguna melalui Internet hanya ke CDN PoP terdekat - Titik Kehadiran. Selalunya ia berada di tempat yang berdekatan. Kemudian ia meninggalkan Internet awam dan terbang melalui tulang belakang peribadi merentasi Atlantik, sebagai contoh, dan terus ke sumber.
Saya tertanya-tanya bagaimana Internet akan berubah dalam 10 tahun jika trend ini berterusan?
Saluran fizikal
Para saintis masih belum mengetahui cara meningkatkan kelajuan cahaya di Alam Semesta, tetapi mereka telah mencapai kemajuan besar dalam kaedah penghantarannya melalui gentian optik. Pada masa ini kami menggunakan kabel gentian 6912. Ini membantu mengoptimumkan kos pemasangannya dengan ketara.
Di sesetengah wilayah kita perlu menggunakan kabel khas. Sebagai contoh, di rantau Sydney kami menggunakan kabel dengan salutan anti-anai khas.
Tiada siapa yang kebal daripada masalah dan kadangkala saluran kita rosak. Foto di sebelah kanan menunjukkan kabel optik di salah satu wilayah Amerika yang koyak oleh pekerja binaan. Akibat kemalangan itu, hanya 13 paket data hilang, yang mengejutkan. Sekali lagi - hanya 13! Sistem secara langsung bertukar kepada saluran sandaran - skala berfungsi.
Kami berlari melalui beberapa perkhidmatan dan teknologi awan Amazon. Saya harap anda mempunyai sekurang-kurangnya sedikit idea tentang skala tugas yang perlu diselesaikan oleh jurutera kami. Secara peribadi, saya mendapati ini sangat menarik.
Ini adalah bahagian akhir trilogi dari Vasily Pantyukhin mengenai peranti AWS. DALAM bahagian menerangkan pengoptimuman pelayan dan penskalaan pangkalan data, dan dalam β fungsi tanpa pelayan dan Mercun.
Pada pada bulan November Vasily Pantyukhin akan berkongsi butiran baharu peranti Amazon. Dia tentang punca kegagalan dan reka bentuk sistem teragih di Amazon. 24 Oktober masih boleh tiket pada harga yang baik, dan bayar kemudian. Kami sedang menunggu anda di HighLoad++, datang dan berbual!
Sumber: www.habr.com