Bagaimana AWS mengolah layanannya yang tangguh. Penskalaan jaringan

Jaringan Amazon Web Services memiliki 69 lokasi di seluruh dunia di 22 wilayah: AS, Eropa, Asia, Afrika, dan Australia. Di setiap zona ada hingga 8 pusat data - Pusat Pemrosesan Data. Setiap pusat data memiliki ribuan atau ratusan ribu server. Jaringan dibangun sedemikian rupa sehingga semua skenario pemadaman yang tidak mungkin diperhitungkan. Misalnya, semua daerah terisolasi satu sama lain, dan zona akses berjarak beberapa kilometer. Bahkan jika Anda memotong kabel, sistem akan beralih ke saluran cadangan, dan kehilangan informasi akan berjumlah unit paket data. Tentang prinsip-prinsip lain apa jaringan itu dibangun dan bagaimana ia dibangun, akan memberi tahu Vasily Pantyukhin.



Vasily Pantyukhin mulai sebagai admin Unix di perusahaan .ru, menghabiskan 6 tahun di kelenjar besar Sun Microsystem, dan selama 11 tahun ia mengkhotbahkan data-sentrisitas dunia di EMC. Secara alami berevolusi menjadi awan pribadi, lalu go public. Sekarang, sebagai arsitek Amazon Web Services, saran teknis membantu Anda hidup dan tumbuh di awan AWS.

Pada bagian sebelumnya dari trilogi perangkat AWS, Vasily menyelidiki perangkat server fisik dan penskalaan basis data. Nitro-card, hypervisor khusus berdasarkan KVM, database Amazon Aurora - semua ini dalam artikel " Bagaimana AWS" memasak "layanan elastisnya. Penskalaan server dan basis data . " Baca untuk menyelami konteksnya, atau tonton video presentasi.

Pada bagian ini, kami akan fokus pada penskalaan jaringan - salah satu sistem paling kompleks di AWS. Evolusi dari jaringan datar ke Virtual Private Cloud dan perangkatnya, layanan Blackfoot dan HyperPlane internal, masalah tetangga yang bising, dan pada akhirnya - skala jaringan, tulang punggung, dan kabel fisik. Tentang semua ini di bawah potongan.

Penafian: segala sesuatu di bawah ini adalah pendapat pribadi Vasily, dan itu mungkin tidak sesuai dengan posisi Amazon Web Services.

Penskalaan jaringan

AWS Cloud diluncurkan pada 2006. Jaringannya cukup primitif - dengan struktur datar. Kisaran alamat pribadi adalah umum untuk semua penyewa cloud. Ketika Anda memulai mesin virtual baru, Anda secara tidak sengaja menerima alamat IP yang tersedia dari kisaran ini.



Pendekatan ini mudah diimplementasikan, tetapi pada dasarnya membatasi penggunaan cloud. Secara khusus, cukup sulit untuk mengembangkan solusi hybrid yang menggabungkan jaringan pribadi di darat dan di AWS. Masalah yang paling umum adalah persimpangan rentang alamat IP.

Cloud pribadi virtual

Awan itu laris. Sudah waktunya untuk memikirkan skalabilitas dan kemungkinan penggunaannya oleh puluhan juta penyewa. Jaringan datar telah menjadi kendala utama. Oleh karena itu, kami memikirkan cara mengisolasi pengguna dari satu sama lain di tingkat jaringan sehingga mereka dapat secara mandiri memilih rentang IP.



Apa yang terlintas dalam pikiran ketika Anda berpikir tentang isolasi jaringan? Tentu saja VLAN dan VRF adalah Virtual Routing dan Forwarding .

Sayangnya, ini tidak berhasil. VLAN ID hanya 12 bit, yang memberi kami hanya 4.096 segmen yang terisolasi. Bahkan di sakelar terbesar, Anda dapat menggunakan maksimal 1-2 ribu VRF. Penggunaan gabungan VRF dan VLAN memberi kami hanya beberapa juta subnet. Ini jelas tidak cukup untuk puluhan juta penyewa, yang masing-masing harus dapat menggunakan beberapa subnet.

Namun, kami tidak dapat membeli jumlah kotak besar yang diperlukan, misalnya, dari Cisco atau Juniper. Ada dua alasan: harganya sangat mahal, dan kami tidak ingin menjadi tergantung pada pengembangan dan kebijakan perbaikan mereka.

Hanya ada satu kesimpulan - untuk memasak keputusan Anda sendiri.

Pada tahun 2009, kami mengumumkan VPC - Virtual Private Cloud . Nama telah berakar dan sekarang banyak penyedia cloud juga menggunakannya.

VPC adalah jaringan virtual Software Defined Network ( SDN ). Kami memutuskan untuk tidak membuat protokol khusus di tingkat L2 dan L3. Jaringan berjalan pada Ethernet dan IP standar. Untuk transmisi melalui jaringan, lalu lintas mesin virtual diringkas dalam bungkus protokol kami sendiri. Ini menunjukkan ID yang dimiliki oleh Tenant VPC.



Kedengarannya mudah. Namun, perlu untuk menyelesaikan beberapa masalah teknis serius. Misalnya, di mana dan bagaimana menyimpan data pemetaan untuk alamat MAC / IP virtual, ID VPC, dan alamat fisik MAC / IP yang sesuai. Pada skala AWS, ini adalah meja besar yang harus bekerja dengan latensi minimal. Layanan pemetaan , yang diolesi dengan lapisan tipis di seluruh jaringan, bertanggung jawab untuk ini.

Dalam mesin generasi baru, enkapsulasi dilakukan oleh kartu Nitro di tingkat besi. Dalam kasus yang lebih lama, enkapsulasi dan dekapsulasi perangkat lunak.



Mari kita lihat bagaimana ini bekerja secara umum. Mari kita mulai dengan level L2. Misalkan kita memiliki mesin virtual dengan IP 10.0.0.2 pada server fisik 192.168.0.3. Ini mengirimkan data ke mesin virtual 10.0.0.3 yang hidup di 192.168.1.4. Permintaan ARP dihasilkan, yang jatuh pada kartu jaringan Nitro. Untuk kesederhanaan, kami percaya bahwa kedua mesin virtual hidup dalam VPC "biru" yang sama.



Kartu tersebut menggantikan alamat sumber dengan miliknya dan mengirimkan bingkai 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 logis dan IP dalam bungkus VPC. Semua ini ditransmisikan melalui jaringan fisik menggunakan kartu Nitro IP yang sesuai dari sumber dan tujuan.



Mesin fisik paket ini dimaksudkan untuk melakukan pemeriksaan. Ini untuk mencegah kemungkinan spoofing. Mesin mengirimkan permintaan khusus ke layanan pemetaan dan bertanya: “Dari mesin fisik 192.168.0.3 Saya menerima paket yang dirancang untuk 10.0.0.3 dalam VPC biru. Apakah dia sah? "



Layanan pemetaan memeriksa tabel alokasi sumber dayanya dan memungkinkan atau menolak jalannya paket. Dalam semua kasus baru, validasi tambahan dijahit dalam kartu Nitro. Tidak mungkin untuk berkeliling bahkan secara teoritis. Karenanya, spoofing ke sumber daya di VPC lain tidak akan berfungsi.



Kemudian data dikirim ke mesin virtual yang memang dimaksudkan.



Layanan pemetaan juga berfungsi sebagai router logis untuk mentransfer data antara mesin virtual pada subnet yang berbeda. Semuanya secara konsep sederhana di sana, saya tidak akan menganalisisnya secara rinci.



Ternyata selama transmisi setiap paket, server mengakses layanan pemetaan. Bagaimana cara mengatasi penundaan yang tak terhindarkan? Caching , tentu saja.

Semua pesona adalah bahwa Anda tidak perlu men-cache seluruh tabel besar. Mesin virtual dari sejumlah VPC yang relatif kecil tinggal di server fisik. Informasi perlu di-cache hanya tentang VPC ini. Mentransfer data ke VPC lain dalam konfigurasi "default" masih tidak sah. Jika fungsi seperti VPC-peering digunakan, informasi tentang VPC terkait juga dimasukkan ke dalam cache.



Dengan transfer data ke VPC tahu.

Blackfoot

Apa yang harus dilakukan dalam kasus ketika lalu lintas harus ditransmisikan ke luar, misalnya, di Internet atau melalui VPN ke darat? Di sinilah Blackfoot , layanan internal AWS, membantu kami keluar. Ini dirancang oleh tim Afrika Selatan kami. Oleh karena itu, layanan ini dinamai penguin yang tinggal di Afrika Selatan.



Blackfoot memecah lalu lintas dan melakukan apa yang dibutuhkannya. Data internet dikirim apa adanya.



Data didekapsulasi dan dibungkus lagi dalam pembungkus IPsec saat menggunakan VPN.



Saat menggunakan Direct Connect, lalu lintas ditandai dan ditransmisikan ke VLAN yang sesuai.

HyperPlane

Ini adalah layanan kontrol aliran internal. Banyak layanan jaringan memerlukan pemantauan status aliran data . Misalnya, ketika menggunakan NAT, kontrol aliran harus memastikan bahwa setiap pasangan "IP: port tujuan" memiliki port keluar unik. Dalam kasus penyeimbang NLB - Network Load Balancer , aliran data harus selalu diarahkan ke mesin virtual target yang sama. Grup Keamanan adalah firewall stateful. Ini memonitor lalu lintas masuk dan secara implisit membuka port untuk aliran paket keluar.



Di cloud AWS, persyaratan latensi transmisi sangat tinggi. Oleh karena itu, HyperPlane sangat penting untuk kesehatan seluruh jaringan.



Hyperplane dibangun di atas mesin virtual EC2. Tidak ada sihir di sini, hanya licik. Triknya adalah mereka adalah mesin virtual dengan RAM besar. Transaksi bersifat transaksional dan dilakukan secara eksklusif dalam memori. Ini memungkinkan untuk penundaan hanya puluhan mikrodetik. Bekerja dengan disk akan mematikan semua kinerja.

Hyperplane adalah sistem terdistribusi dari sejumlah besar mesin EC2 tersebut. Setiap mesin virtual memiliki bandwidth 5 GB / s. Di seluruh jaringan regional, ini menghasilkan bandwidth terabit liar dan memungkinkan Anda untuk memproses jutaan koneksi per detik .

HyperPlane hanya berfungsi dengan utas. Enkapsulasi paket VPC sepenuhnya transparan baginya. Potensi kerentanan dalam layanan internal ini masih tidak memungkinkan untuk menembus isolasi VPC. Untuk keselamatan, level di bawah ini bertanggung jawab.

Tetangga yang bising

Ada juga masalah tetangga yang berisik . Misalkan kita memiliki 8 node. Node-node ini memproses utas dari semua pengguna cloud. Semuanya tampak baik-baik saja dan bebannya harus didistribusikan secara merata di semua node. Node sangat kuat dan sulit untuk dibebani terlalu banyak.

Tapi kami sedang membangun arsitektur kami berdasarkan skenario yang bahkan tidak mungkin.

Probabilitas rendah tidak berarti ketidakmungkinan.

Kita dapat membayangkan situasi di mana satu atau lebih pengguna akan menghasilkan terlalu banyak beban. Semua node HyperPlane terlibat dalam memproses beban ini, dan pengguna lain berpotensi merasakan semacam penurunan kinerja. Ini menghancurkan konsep cloud, di mana penyewa tidak memiliki cara untuk saling mempengaruhi.



Bagaimana mengatasi masalah tetangga yang bising? Hal pertama yang terlintas dalam pikiran adalah sharding. 8 node kami secara logis dibagi menjadi 4 pecahan dengan 2 node di masing-masing. Sekarang, tetangga yang berisik akan dihambat oleh hanya seperempat dari semua pengguna, tetapi lebih dari itu.



Mari kita lakukan secara berbeda. Setiap pengguna hanya dialokasikan 3 node.



Caranya adalah dengan menetapkan node ke pengguna yang berbeda secara acak. 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 berisik menyeberang dengan salah satu pengguna adalah 54%. Dengan probabilitas ini bahwa pengguna biru akan mempengaruhi penyewa lain. Apalagi hanya sebagian dari bebannya. Dalam contoh kami, pengaruh ini akan setidaknya entah bagaimana tidak terlihat oleh semua orang, tetapi hanya sepertiga dari semua pengguna. Ini sudah hasil yang bagus.

Mari kita membawa situasi lebih dekat ke yang asli - ambil 100 node dan 5 pengguna pada 5 node. Dalam hal ini, tidak ada node yang bersinggungan dengan probabilitas 77%.

Dalam situasi nyata dengan sejumlah besar node dan pengguna HyperPlane, dampak potensial dari tetangga yang bising terhadap pengguna lain adalah minimal. Metode ini disebut shuffle sharding . Ini meminimalkan efek negatif dari kegagalan simpul.

Berdasarkan HyperPlane banyak layanan dibangun: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

Skala jaringan

Sekarang mari kita bicara tentang skala jaringan itu sendiri. Untuk Oktober 2019, AWS menawarkan layanannya di 22 wilayah , dan 9 lainnya direncanakan.

• Setiap wilayah mengandung beberapa Zona Ketersediaan. Ada 69 di antaranya di dunia.
  
• Setiap AZ terdiri dari Pusat Pemrosesan Data. Tidak ada lebih dari 8 dari mereka.
  
• Di pusat data ada sejumlah besar server, beberapa hingga 300.000.
  

Sekarang semua ini dirata-rata, dikalikan dan dapatkan angka yang mengesankan yang menampilkan skala cloud Amazon .

Antara zona akses dan pusat data, banyak saluran optik diletakkan. Di salah satu wilayah terbesar kami, hanya 388 saluran telah dipasang untuk koneksi antara AZ dan pusat komunikasi dengan wilayah lain (Pusat Transit). Secara total, ini memberikan 5000 Tbit gila.



AWS Backbone dibangun khusus untuk cloud dan dioptimalkan untuk bekerja dengannya. Kami membangunnya di saluran 100 GB / s . Kami sepenuhnya mengendalikan mereka, dengan pengecualian wilayah di Cina. Lalu lintas tidak dibagi dengan banyak perusahaan lain.



Tentu saja, kami bukan satu-satunya penyedia cloud dengan jaringan backbone pribadi. Semakin banyak perusahaan besar seperti ini. Ini dikonfirmasi oleh para peneliti independen, misalnya, dari Telegeography .



Grafik menunjukkan bahwa pangsa penyedia konten dan penyedia cloud tumbuh. Karena itu, proporsi lalu lintas Internet dari penyedia backbone terus menurun.

Saya akan menjelaskan mengapa ini terjadi. Sebelumnya, sebagian besar layanan web tersedia dan dikonsumsi langsung dari Internet. Sekarang semakin banyak server yang berada di cloud dan tersedia melalui CDN - Content Distribution Network . Untuk mengakses sumber daya, pengguna pergi melalui Internet hanya ke CDN PoP - Point of Presence terdekat . Paling sering itu di suatu tempat di dekatnya. Lalu dia meninggalkan Internet publik dan terbang melalui Atlantik melalui tulang punggung pribadi, misalnya, dan langsung menuju sumber daya.

Saya ingin tahu bagaimana Internet akan berubah dalam 10 tahun jika tren ini berlanjut?

Saluran fisik

Para ilmuwan belum menemukan cara untuk meningkatkan kecepatan cahaya di alam semesta, tetapi telah membuat kemajuan besar dalam metode mentransmisikannya melalui serat optik. Kami saat ini menggunakan 6912 kabel serat. Ini membantu untuk secara signifikan mengoptimalkan biaya pemasangannya.

Di beberapa daerah kita harus menggunakan kabel khusus. Misalnya, di wilayah Sydney, kami menggunakan kabel dengan lapisan khusus untuk melawan rayap.



Tidak ada yang aman dari masalah dan terkadang saluran kami rusak. Foto di sebelah kanan menunjukkan kabel optik di salah satu wilayah Amerika yang robek oleh pembangun. Akibat kecelakaan itu, hanya 13 paket data yang hilang, yang mengejutkan. Sekali lagi - hanya 13! Sistem secara harfiah langsung beralih ke saluran cadangan - skalanya berfungsi.

Kami berlari cepat melewati beberapa layanan dan teknologi cloud Amazon. Saya harap Anda memiliki setidaknya beberapa gagasan tentang skala tugas yang harus diselesaikan oleh teknisi kami. Secara pribadi, saya sangat tertarik dengan ini.

Ini adalah bagian terakhir dari trilogi dari Vasily Pantyukhin tentang perangkat AWS. Bagian pertama menjelaskan pengoptimalan server dan penskalaan basis data, dan yang kedua menjelaskan fungsi tanpa server dan Petasan.

Di HighLoad ++ pada bulan November, Vasily Pantyukhin akan membagikan detail perangkat Amazon baru. Dia akan berbicara tentang penyebab kegagalan dan desain sistem terdistribusi di Amazon. Pada 24 Oktober, Anda masih bisa memesan tiket dengan harga bagus, dan membayar kemudian. Kami menunggu Anda di HighLoad ++, datang dan bicara!