Skala jaringan Amazon Web Services adalah 69 zona di seluruh dunia di 22 wilayah: AS, Eropa, Asia, Afrika, dan Australia. Setiap zona berisi hingga 8 pusat data - Pusat Pemrosesan Data. Setiap pusat data memiliki ribuan atau ratusan ribu server. Jaringan dirancang sedemikian rupa sehingga semua skenario pemadaman yang tidak terduga dapat diperhitungkan. Misalnya, semua wilayah terisolasi satu sama lain, dan zona aksesibilitas dipisahkan dalam jarak beberapa kilometer. Bahkan jika Anda memotong kabelnya, sistem akan beralih ke saluran cadangan, dan hilangnya informasi akan berjumlah beberapa paket data. Vasily Pantyukhin akan berbicara tentang prinsip-prinsip lain yang mendasari jaringan ini dan bagaimana strukturnya.
Vasily Pantyukhin dimulai sebagai administrator Unix di perusahaan .ru, bekerja pada perangkat keras Sun Microsystem besar selama 6 tahun, dan mengkhotbahkan dunia yang berpusat pada data selama 11 tahun di EMC. Secara alami, ini berevolusi menjadi cloud pribadi, lalu dipindahkan ke cloud publik. Kini, sebagai arsitek Amazon Web Services, dia memberikan saran teknis untuk membantu hidup dan berkembang di cloud AWS.
Di bagian sebelumnya dari trilogi AWS, Vasily mempelajari desain server fisik dan penskalaan database. Kartu Nitro, hypervisor khusus berbasis KVM, database Amazon Aurora - semua ini ada di materi "" Baca untuk mengetahui konteksnya atau tonton pidato.
Bagian ini akan fokus pada penskalaan jaringan, salah satu sistem paling kompleks di AWS. Evolusi dari jaringan datar ke Virtual Private Cloud dan desainnya, layanan internal Blackfoot dan HyperPlane, masalah tetangga yang bising, dan pada akhirnya - skala jaringan, tulang punggung, dan kabel fisik. Tentang semua ini di bawah pemotongan.
Penafian: semua yang di bawah ini adalah pendapat pribadi Vasily dan mungkin tidak sesuai dengan posisi Amazon Web Services.
Penskalaan jaringan
AWS cloud diluncurkan pada tahun 2006. Jaringannya cukup primitif - dengan struktur datar. Kisaran alamat pribadi adalah hal yang umum bagi semua penyewa cloud. Saat memulai mesin virtual baru, Anda secara tidak sengaja menerima alamat IP yang tersedia dari kisaran ini.
Pendekatan ini mudah diterapkan, namun pada dasarnya membatasi penggunaan cloud. Secara khusus, cukup sulit untuk mengembangkan solusi hibrid yang menggabungkan jaringan pribadi di lapangan dan di AWS. Masalah paling umum adalah rentang alamat IP yang tumpang tindih.
Cloud Pribadi Virtual
Cloud ternyata diminati. Waktunya telah tiba untuk memikirkan skalabilitas dan kemungkinan penggunaannya oleh puluhan juta penyewa. Jaringan datar menjadi kendala utama. Oleh karena itu, kami memikirkan cara mengisolasi pengguna satu sama lain di tingkat jaringan sehingga mereka dapat memilih rentang IP secara mandiri.
Apa hal pertama yang terlintas dalam pikiran Anda ketika memikirkan tentang isolasi jaringan? Tentu VLAN и VRF - Perutean dan Penerusan Virtual.
Sayangnya, itu tidak berhasil. VLAN ID hanya 12 bit, yang memberi kita hanya 4096 segmen terisolasi. Bahkan switch terbesar pun bisa menggunakan maksimal 1-2 ribu VRF. Menggunakan VRF dan VLAN secara bersamaan hanya memberi kita beberapa juta subnet. Ini jelas tidak cukup untuk puluhan juta penyewa, yang masing-masing penyewa harus dapat menggunakan beberapa subnet.
Kami juga tidak mampu membeli kotak besar dalam jumlah yang dibutuhkan, misalnya dari Cisco atau Juniper. Ada dua alasan: biayanya sangat mahal, dan kami tidak ingin bergantung pada kebijakan pengembangan dan perbaikan mereka.
Hanya ada satu kesimpulan - buatlah solusi Anda sendiri.
Pada tahun 2009 kami mengumumkan VPC - Cloud Pribadi Virtual. Nama tersebut mencuat dan kini banyak juga penyedia cloud yang menggunakannya.
VPC adalah jaringan virtual SDN (Jaringan Buatan Perangkat Lunak). Kami memutuskan untuk tidak menciptakan protokol khusus di level L2 dan L3. Jaringan berjalan pada Ethernet dan IP standar. Untuk transmisi melalui jaringan, lalu lintas mesin virtual dikemas dalam pembungkus protokol kami sendiri. Ini menunjukkan ID milik VPC penyewa.
Kedengarannya sederhana. Namun, ada beberapa tantangan teknis serius yang perlu diatasi. Misalnya, di mana dan bagaimana menyimpan data pada pemetaan alamat MAC/IP virtual, ID VPC, dan MAC/IP fisik terkait. Pada skala AWS, ini adalah tabel besar yang dapat berfungsi dengan penundaan akses minimal. Bertanggung jawab untuk ini layanan pemetaan, yang tersebar dalam lapisan tipis di seluruh jaringan.
Pada mesin generasi baru, enkapsulasi dilakukan oleh kartu Nitro di tingkat perangkat keras. Dalam contoh lama, enkapsulasi dan dekapsulasi berbasis perangkat lunak.
Mari kita lihat cara kerjanya secara umum. Mari kita mulai dengan level L2. Misalkan kita memiliki mesin virtual dengan IP 10.0.0.2 di server fisik 192.168.0.3. Ia mengirimkan data ke mesin virtual 10.0.0.3, yang hidup di 192.168.1.4. Permintaan ARP dibuat dan dikirim ke kartu Nitro jaringan. Untuk mempermudah, kami berasumsi bahwa kedua mesin virtual berada di VPC “biru” yang sama.
Peta tersebut menggantikan alamat sumber dengan alamatnya sendiri dan meneruskan frame ARP ke layanan pemetaan.
Layanan pemetaan mengembalikan informasi yang diperlukan untuk transmisi melalui jaringan fisik L2.
Kartu Nitro dalam respons ARP menggantikan MAC di jaringan fisik dengan alamat di VPC.
Saat mentransfer data, kami membungkus MAC dan IP logis dalam pembungkus VPC. Kami mengirimkan semua ini melalui jaringan fisik menggunakan kartu Nitro IP sumber dan tujuan yang sesuai.
Mesin fisik tujuan paket melakukan pemeriksaan. Hal ini diperlukan untuk mencegah kemungkinan terjadinya spoofing alamat. Mesin mengirimkan permintaan khusus ke layanan pemetaan dan menanyakan: “Dari mesin fisik 192.168.0.3 saya menerima paket yang ditujukan untuk 10.0.0.3 di VPC biru. Apakah dia sah?
Layanan pemetaan memeriksa tabel alokasi sumber dayanya dan mengizinkan atau menolak paket untuk melewatinya. Dalam semua kasus baru, validasi tambahan tertanam dalam kartu Nitro. Tidak mungkin untuk mengabaikannya bahkan secara teoritis. Oleh karena itu, spoofing terhadap sumber daya di VPC lain tidak akan berfungsi.
Selanjutnya, data dikirim ke mesin virtual yang dituju.
Layanan pemetaan juga berfungsi sebagai router logis untuk mentransfer data antar mesin virtual di subnet berbeda. Semuanya secara konseptual sederhana, saya tidak akan menjelaskannya secara detail.
Ternyata ketika setiap paket ditransmisikan, server beralih ke layanan pemetaan. Bagaimana cara mengatasi penundaan yang tidak bisa dihindari? cache, tentu saja.
Keindahannya adalah Anda tidak perlu menyimpan seluruh tabel besar dalam cache. Server fisik menghosting mesin virtual dari sejumlah VPC yang relatif kecil. Anda hanya perlu menyimpan informasi tentang VPC ini dalam cache. Mentransfer data ke VPC lain dalam konfigurasi “default” masih tidak sah. Jika fungsionalitas seperti peering VPC digunakan, maka informasi tentang VPC terkait juga dimuat ke dalam cache.
Kami menyelesaikan transfer data ke VPC.
Blackfoot
Apa yang harus dilakukan jika lalu lintas perlu ditransmisikan ke luar, misalnya ke Internet atau melalui VPN ke darat? Membantu kami di sini Blackfoot — Layanan internal AWS. Ini dikembangkan oleh tim Afrika Selatan kami. Itu sebabnya layanan ini dinamai seekor penguin yang tinggal di Afrika Selatan.
Blackfoot mendekapsulasi lalu lintas dan melakukan apa yang diperlukan dengannya. Data dikirim ke Internet apa adanya.
Data didekapsulasi dan dibungkus ulang dalam IPsec saat menggunakan VPN.
Saat menggunakan Direct Connect, lalu lintas ditandai dan dikirim ke VLAN yang sesuai.
Pesawat Hiper
Ini adalah layanan kontrol aliran internal. Banyak layanan jaringan memerlukan pemantauan keadaan aliran data. Misalnya, saat menggunakan NAT, kontrol aliran harus memastikan bahwa setiap pasangan IP:port tujuan memiliki port keluar yang unik. Dalam hal penyeimbang NLB - Penyeimbang Beban Jaringan, aliran data harus selalu diarahkan ke mesin virtual target yang sama. Grup Keamanan adalah firewall berstatus. Ini memonitor lalu lintas masuk dan secara implisit membuka port untuk aliran paket keluar.
Di cloud AWS, persyaratan latensi transmisi sangat tinggi. Itu sebabnya Pesawat Hiper penting untuk kinerja seluruh jaringan.
Hyperplane dibangun di atas mesin virtual EC2. Tidak ada keajaiban di sini, hanya kelicikan. Triknya adalah ini adalah mesin virtual dengan RAM besar. Operasi bersifat transaksional dan dilakukan secara eksklusif di memori. Hal ini memungkinkan Anda mencapai penundaan hanya puluhan mikrodetik. Bekerja dengan disk akan mematikan semua produktivitas.
Hyperplane adalah sistem terdistribusi dari sejumlah besar mesin EC2. Setiap mesin virtual memiliki bandwidth 5 GB/s. Di seluruh jaringan regional, ini memberikan bandwidth yang luar biasa besarnya dan memungkinkan pemrosesan jutaan koneksi per detik.
HyperPlane hanya bekerja dengan aliran. Enkapsulasi paket VPC sepenuhnya transparan. Potensi kerentanan dalam layanan internal ini masih akan mencegah rusaknya isolasi VPC. Tingkat di bawah bertanggung jawab atas keamanan.
Tetangga yang berisik
Masih ada masalah tetangga yang berisik - tetangga berisik. Anggaplah kita memiliki 8 node. Node ini memproses aliran semua pengguna cloud. Semuanya tampak baik-baik saja dan beban harus didistribusikan secara merata ke semua node. Node sangat kuat dan sulit untuk membebani mereka secara berlebihan.
Namun kami membangun arsitektur kami berdasarkan skenario yang bahkan tidak mungkin terjadi.
Kemungkinan yang rendah bukan berarti tidak mungkin.
Kita dapat membayangkan situasi di mana satu atau lebih pengguna menghasilkan terlalu banyak beban. Semua node HyperPlane terlibat dalam pemrosesan beban ini dan pengguna lain berpotensi mengalami semacam penurunan kinerja. Hal ini mematahkan konsep cloud, yang mana penyewa tidak memiliki kemampuan untuk saling mempengaruhi.
Bagaimana cara mengatasi masalah tetangga yang berisik? Hal pertama yang terlintas dalam pikiran adalah sharding. 8 node kami secara logis dibagi menjadi 4 pecahan yang masing-masing terdiri dari 2 node. Sekarang tetangga yang berisik hanya akan mengganggu seperempat dari seluruh pengguna, namun akan sangat mengganggu mereka.
Mari kita lakukan sesuatu secara berbeda. Kami hanya akan mengalokasikan 3 node untuk setiap pengguna.
Caranya adalah dengan menetapkan node secara acak ke pengguna yang berbeda. Pada gambar di bawah, pengguna biru memotong node dengan salah satu dari dua pengguna lainnya - hijau dan oranye.
Dengan 8 node dan 3 pengguna, kemungkinan tetangga yang berisik berpotongan dengan salah satu pengguna adalah 54%. Dengan kemungkinan inilah pengguna biru akan mempengaruhi penyewa lainnya. Pada saat yang sama, hanya sebagian dari bebannya. Dalam contoh kita, pengaruh ini setidaknya akan terlihat tidak oleh semua orang, tetapi hanya sepertiga dari semua pengguna. Ini sudah merupakan hasil yang bagus.
Jumlah pengguna yang akan berpotongan
Probabilitas dalam persen
0
18%
1
54%
2
26%
3
2%
Mari kita membawa situasi ini lebih dekat ke kenyataan - mari kita ambil 100 node dan 5 pengguna dalam 5 node. Dalam hal ini, tidak ada satupun node yang berpotongan dengan probabilitas 77%.
Jumlah pengguna yang akan berpotongan
Probabilitas dalam persen
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Dalam situasi nyata, dengan sejumlah besar node dan pengguna HyperPlane, potensi dampak dari tetangga yang berisik terhadap pengguna lain sangatlah kecil. Metode ini disebut pencampuran pecahan - mengacak sharding. Ini meminimalkan efek negatif dari kegagalan node.
Banyak layanan yang dibangun berdasarkan HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Skala jaringan
Sekarang mari kita bicara tentang skala jaringan itu sendiri. Untuk bulan Oktober 2019 AWS menawarkan layanannya di 22 wilayah, dan 9 lainnya direncanakan.
- Setiap wilayah berisi beberapa Availability Zone. Ada 69 di antaranya di seluruh dunia.
- Setiap AZ terdiri dari Pusat Pengolahan Data. Totalnya tidak lebih dari 8.
- Pusat data menampung sejumlah besar server, beberapa di antaranya mencapai hingga 300.
Sekarang mari kita ratakan semua ini, kalikan dan dapatkan angka mengesankan yang mencerminkannya Skala cloud Amazon.
Ada banyak tautan optik antara Availability Zone dan pusat data. Di salah satu wilayah terbesar kami, 388 saluran telah dipasang hanya untuk komunikasi AZ antara satu sama lain dan pusat komunikasi dengan wilayah lain (Pusat Transit). Secara total, ini membuat gila 5000 TB.
Backbone AWS dibuat khusus dan dioptimalkan untuk cloud. Kami membangunnya di saluran 100 GB / detik. Kami mengendalikannya sepenuhnya, kecuali wilayah di Tiongkok. Lalu lintas tidak dibagi dengan banyak perusahaan lain.
Tentu saja, kami bukan satu-satunya penyedia cloud dengan jaringan tulang punggung pribadi. Semakin banyak perusahaan besar yang mengikuti jalur ini. Hal ini dibenarkan oleh peneliti independen, misalnya dari .
Grafik tersebut menunjukkan bahwa pangsa penyedia konten dan penyedia cloud semakin meningkat. Oleh karena itu, porsi lalu lintas Internet dari penyedia backbone terus menurun.
Saya akan menjelaskan mengapa ini terjadi. Sebelumnya, sebagian besar layanan web dapat diakses dan dikonsumsi langsung dari Internet. Saat ini, semakin banyak server yang berlokasi di cloud dan dapat diakses melalui CDN - Jaringan Distribusi Konten. Untuk mengakses sumber daya, pengguna melalui Internet hanya ke CDN PoP terdekat - Titik Kehadiran. Paling sering itu ada di suatu tempat di dekatnya. Kemudian ia meninggalkan Internet publik dan terbang melalui jaringan pribadi melintasi Atlantik, misalnya, dan langsung mengakses sumber daya tersebut.
Saya bertanya-tanya bagaimana Internet akan berubah dalam 10 tahun jika tren ini terus berlanjut?
Saluran fisik
Para ilmuwan belum menemukan cara untuk meningkatkan kecepatan cahaya di alam semesta, namun mereka telah membuat kemajuan besar dalam metode transmisi melalui serat optik. Saat ini kami menggunakan 6912 kabel fiber. Ini membantu mengoptimalkan biaya pemasangannya secara signifikan.
Di beberapa daerah kita harus menggunakan kabel khusus. Misalnya, di wilayah Sydney kami menggunakan kabel dengan lapisan khusus anti rayap.
Tidak ada seorang pun yang kebal dari masalah dan terkadang saluran kita rusak. Foto sebelah kanan menunjukkan kabel optik di salah satu wilayah Amerika yang dirobek oleh pekerja konstruksi. Akibat kecelakaan tersebut, hanya 13 paket data yang hilang, hal ini cukup mengejutkan. Sekali lagi - hanya 13! Sistem benar-benar langsung beralih ke saluran cadangan - skalanya berfungsi.
Kami menjelajahi beberapa layanan dan teknologi cloud Amazon. Saya harap Anda setidaknya memiliki gambaran tentang skala tugas yang harus diselesaikan oleh teknisi kami. Secara pribadi, menurut saya ini sangat menarik.
Ini adalah bagian terakhir dari trilogi Vasily Pantyukhin tentang perangkat AWS. DI DALAM bagian menjelaskan optimasi server dan penskalaan basis data, dan masuk — fungsi tanpa server dan Petasan.
Pada pada bulan November Vasily Pantyukhin akan membagikan detail baru perangkat Amazon. Dia tentang penyebab kegagalan dan desain sistem terdistribusi di Amazon. Tanggal 24 Oktober masih memungkinkan tiket dengan harga bagus, dan bayar nanti. Kami menunggu Anda di HighLoad++, datang dan ngobrol!
Sumber: www.habr.com