Web moden hampir tidak dapat difikirkan tanpa kandungan media: hampir setiap nenek mempunyai telefon pintar, semua orang berada di rangkaian sosial, dan masa henti dalam penyelenggaraan adalah mahal untuk syarikat. Berikut adalah transkrip kisah syarikat tentang cara dia mengatur penghantaran foto menggunakan penyelesaian perkakasan, apakah masalah prestasi yang dia hadapi dalam proses itu, apa yang menyebabkannya, dan bagaimana masalah ini diselesaikan menggunakan penyelesaian perisian berdasarkan Nginx, sambil memastikan toleransi kesalahan di semua peringkat (). Kami berterima kasih kepada pengarang cerita Oleg Efimova dan Alexandra Dymova, yang berkongsi pengalaman mereka di persidangan itu .
β Mari mulakan dengan sedikit pengenalan tentang cara kami menyimpan dan menyimpan foto. Kami mempunyai lapisan tempat kami menyimpannya, dan lapisan tempat kami menyimpan foto. Pada masa yang sama, jika kami ingin mencapai kadar helah yang tinggi dan mengurangkan beban pada storan, adalah penting bagi kami bahawa setiap foto pengguna individu berada pada satu pelayan caching. Jika tidak, kami perlu memasang lebih banyak cakera kerana kami mempunyai lebih banyak pelayan. Kadar helah kami adalah sekitar 99%, iaitu, kami mengurangkan beban pada storan kami sebanyak 100 kali, dan untuk melakukan ini, 10 tahun yang lalu, ketika semua ini sedang dibina, kami mempunyai 50 pelayan. Sehubungan itu, untuk menyampaikan foto ini, kami pada asasnya memerlukan 50 domain luaran yang disediakan oleh pelayan ini.
Sememangnya, persoalan segera timbul: jika salah satu pelayan kami rosak dan tidak tersedia, bahagian trafik manakah yang kami hilang? Kami melihat apa yang ada di pasaran dan memutuskan untuk membeli sekeping perkakasan supaya ia dapat menyelesaikan semua masalah kami. Pilihan jatuh pada penyelesaian syarikat rangkaian F5 (yang, dengan cara itu, baru-baru ini membeli NGINX, Inc): Pengurus Trafik Tempatan BIG-IP.
Perkara yang dilakukan oleh perkakasan (LTM) ini: ia ialah penghala besi yang menjadikan lebihan besi pada port luarannya dan membolehkan anda menghalakan trafik berdasarkan topologi rangkaian, pada beberapa tetapan dan melakukan pemeriksaan kesihatan. Adalah penting bagi kami bahawa perkakasan ini boleh diprogramkan. Sehubungan itu, kami boleh menerangkan logik bagaimana gambar pengguna tertentu dihidangkan daripada cache tertentu. Bagaimana rupanya? Terdapat sekeping perkakasan yang melihat Internet pada satu domain, satu IP, melakukan pemuatan ssl, menghuraikan permintaan http, memilih nombor cache daripada IRule, ke mana hendak pergi, dan membenarkan trafik ke sana. Pada masa yang sama, ia melakukan pemeriksaan kesihatan, dan sekiranya beberapa mesin tidak tersedia, pada masa itu kami membuatnya supaya trafik pergi ke satu pelayan sandaran. Dari sudut pandangan konfigurasi, sudah tentu terdapat beberapa nuansa, tetapi secara umum semuanya agak mudah: kami mendaftarkan kad, surat-menyurat nombor tertentu ke IP kami di rangkaian, kami mengatakan bahawa kami akan mendengar pada port 80 dan 443, kami mengatakan bahawa jika pelayan tidak tersedia, maka anda perlu menghantar trafik ke sandaran, dalam kes ini ke-35, dan kami menerangkan sekumpulan logik tentang cara seni bina ini harus dibongkar. Satu-satunya masalah ialah bahasa di mana perkakasan diprogramkan ialah Tcl. Jika sesiapa mengingati ini sama sekali... bahasa ini lebih kepada menulis sahaja daripada bahasa yang sesuai untuk pengaturcaraan:
Apa yang kita dapat? Kami menerima sekeping perkakasan yang memastikan ketersediaan infrastruktur kami yang tinggi, mengarahkan semua trafik kami, memberikan manfaat kesihatan dan berfungsi dengan baik. Lebih-lebih lagi, ia berfungsi untuk masa yang agak lama: sepanjang 10 tahun yang lalu tidak ada aduan mengenainya. Menjelang awal tahun 2018, kami telah pun menghantar kira-kira 80k foto sesaat. Ini adalah sekitar 80 gigabit trafik dari kedua-dua pusat data kami.
Tetapiβ¦
Pada awal tahun 2018, kami melihat gambar hodoh pada carta: masa yang diambil untuk menghantar foto telah meningkat dengan jelas. Dan ia berhenti sesuai dengan kami. Masalahnya ialah tingkah laku ini hanya kelihatan semasa puncak trafik - untuk syarikat kami ini adalah malam dari Ahad hingga Isnin. Tetapi selebihnya sistem berkelakuan seperti biasa, tiada tanda-tanda kegagalan.
Namun begitu, masalah itu terpaksa diselesaikan. Kami mengenal pasti kemungkinan kesesakan dan mula menghapuskannya. Pertama sekali, sudah tentu, kami mengembangkan pautan atas luaran, menjalankan audit lengkap pautan atas dalaman dan menemui semua kemungkinan kesesakan. Tetapi semua ini tidak memberikan hasil yang jelas, masalah itu tidak hilang.
Satu lagi kesesakan yang mungkin adalah prestasi cache foto itu sendiri. Dan kami memutuskan bahawa mungkin masalahnya terletak pada mereka. Nah, kami mengembangkan prestasi - terutamanya port rangkaian pada cache foto. Tetapi sekali lagi tiada peningkatan yang jelas dilihat. Pada akhirnya, kami memberi perhatian kepada prestasi LTM itu sendiri, dan di sini kami melihat gambar yang menyedihkan pada graf: beban pada semua CPU mula berjalan lancar, tetapi kemudian tiba-tiba datang ke dataran tinggi. Pada masa yang sama, LTM berhenti bertindak balas secukupnya kepada pemeriksaan kesihatan dan pautan naik dan mula mematikannya secara rawak, yang membawa kepada kemerosotan prestasi yang serius.
Iaitu, kami telah mengenal pasti punca masalah, mengenal pasti kesesakan. Ia kekal untuk memutuskan apa yang akan kita lakukan.
Perkara pertama yang paling jelas yang boleh kita lakukan ialah memodenkan LTM itu sendiri. Tetapi terdapat beberapa nuansa di sini, kerana perkakasan ini agak unik, anda tidak akan pergi ke pasar raya terdekat dan membelinya. Ini adalah kontrak berasingan, kontrak lesen berasingan, dan ia akan mengambil banyak masa. Pilihan kedua adalah untuk mula berfikir sendiri, tampil dengan penyelesaian anda sendiri menggunakan komponen anda sendiri, sebaik-baiknya menggunakan program akses terbuka. Apa yang tinggal ialah memutuskan apa sebenarnya yang akan kami pilih untuk ini dan berapa banyak masa yang akan kami habiskan untuk menyelesaikan masalah ini, kerana pengguna tidak menerima foto yang mencukupi. Oleh itu, kita perlu melakukan semua ini dengan sangat, sangat cepat, boleh dikatakan semalam.
Memandangkan tugas itu berbunyi seperti "buat sesuatu secepat mungkin dan menggunakan perkakasan yang kami ada," perkara pertama yang kami fikirkan adalah dengan hanya mengeluarkan beberapa mesin yang tidak begitu berkuasa dari hadapan, meletakkan Nginx di sana, yang kami tahu bagaimana untuk bekerja dan cuba melaksanakan semua logik yang sama yang digunakan oleh perkakasan. Sebenarnya, kami meninggalkan perkakasan kami, memasang 4 lagi pelayan yang perlu kami konfigurasikan, mencipta domain luaran untuk mereka, sama seperti 10 tahun lalu... Kami kehilangan sedikit ketersediaan jika mesin ini jatuh, tetapi masih kurang, mereka menyelesaikan masalah pengguna kami secara tempatan.
Oleh itu, logiknya tetap sama: kami memasang Nginx, ia boleh melakukan SSL-offload, kami boleh memprogramkan logik penghalaan, pemeriksaan kesihatan dalam konfigurasi dan hanya menduplikasi logik yang kami ada sebelum ini.
Mari duduk untuk menulis konfigurasi. Pada mulanya nampaknya semuanya sangat mudah, tetapi, malangnya, sangat sukar untuk mencari manual untuk setiap tugas. Oleh itu, kami tidak mengesyorkan hanya googling "cara mengkonfigurasi Nginx untuk foto": lebih baik merujuk kepada dokumentasi rasmi, yang akan menunjukkan tetapan mana yang harus disentuh. Tetapi lebih baik untuk memilih sendiri parameter tertentu. Nah, semuanya mudah: kami menerangkan pelayan yang kami ada, kami menerangkan sijil... Tetapi perkara yang paling menarik ialah, sebenarnya, logik penghalaan itu sendiri.
Pada mulanya nampaknya kami hanya menerangkan lokasi kami, memadankan nombor cache foto kami di dalamnya, menggunakan tangan kami atau penjana untuk menerangkan berapa banyak hulu yang kami perlukan, di setiap hulu kami menunjukkan pelayan yang sepatutnya digunakan oleh trafik. pergi, dan pelayan sandaran - jika pelayan utama tidak tersedia:
Tetapi, mungkin, jika semuanya begitu mudah, kami hanya akan pulang ke rumah dan tidak berkata apa-apa. Malangnya, dengan tetapan Nginx lalai, yang, secara amnya, telah dibuat selama bertahun-tahun pembangunan dan tidak sepenuhnya sesuai untuk kes ini... konfigurasi kelihatan seperti ini: jika sesetengah pelayan huluan mempunyai ralat permintaan atau tamat masa, Nginx sentiasa menukar trafik ke yang seterusnya. Selain itu, selepas kegagalan pertama, dalam masa 10 saat pelayan juga akan dimatikan, secara tidak sengaja dan tamat masa - ini tidak boleh dikonfigurasikan dalam apa jua cara. Iaitu, jika kami mengalih keluar atau menetapkan semula pilihan tamat masa dalam arahan huluan, maka, walaupun Nginx tidak akan memproses permintaan ini dan akan bertindak balas dengan beberapa ralat yang tidak begitu baik, pelayan akan ditutup.
Untuk mengelakkan ini, kami melakukan dua perkara:
a) mereka melarang Nginx daripada melakukan ini secara manual - dan malangnya, satu-satunya cara untuk melakukan ini adalah dengan hanya menetapkan tetapan maks gagal.
b) kami ingat bahawa dalam projek lain kami menggunakan modul yang membolehkan kami melakukan pemeriksaan kesihatan latar belakang - sewajarnya, kami melakukan pemeriksaan kesihatan yang agak kerap supaya masa henti sekiranya berlaku kemalangan adalah minimum.
Malangnya, ini bukan semua, kerana secara literal dua minggu pertama operasi skim ini menunjukkan bahawa pemeriksaan kesihatan TCP juga merupakan perkara yang tidak boleh dipercayai: pada pelayan hulu ia mungkin bukan Nginx, atau Nginx dalam D-state, dan dalam kes ini kernel akan menerima sambungan, pemeriksaan kesihatan akan lulus, tetapi tidak akan berfungsi. Oleh itu, kami segera menggantikannya dengan http semakan kesihatan, membuat yang khusus, yang, jika ia mengembalikan 200, maka semuanya berfungsi dalam skrip ini. Anda boleh melakukan logik tambahan - sebagai contoh, dalam kes pelayan caching, pastikan sistem fail dipasang dengan betul:
Dan ini sesuai dengan kami, kecuali pada masa ini litar mengulangi sepenuhnya apa yang dilakukan oleh perkakasan. Tetapi kami mahu melakukan yang lebih baik. Sebelum ini, kami mempunyai satu pelayan sandaran, dan ini mungkin tidak begitu baik, kerana jika anda mempunyai seratus pelayan, maka apabila beberapa gagal sekaligus, satu pelayan sandaran tidak mungkin dapat menampung beban. Oleh itu, kami memutuskan untuk mengedarkan tempahan ke semua pelayan: kami hanya membuat satu lagi huluan berasingan, menulis semua pelayan di sana dengan parameter tertentu mengikut beban yang boleh mereka sediakan, menambah pemeriksaan kesihatan yang sama yang kami lakukan sebelum ini :
Memandangkan mustahil untuk pergi ke huluan yang lain dalam satu huluan, adalah perlu untuk memastikan bahawa jika huluan utama, di mana kami hanya merekodkan cache foto yang betul dan diperlukan, tidak tersedia, kami hanya melalui error_page untuk mundur, daripada di mana kami pergi ke hulu sandaran:
Dan dengan menambah empat pelayan secara literal, inilah yang kami dapat: kami menggantikan sebahagian daripada beban - kami mengalihkannya dari LTM ke pelayan ini, melaksanakan logik yang sama di sana, menggunakan perkakasan dan perisian standard, dan serta-merta menerima bonus yang pelayan ini boleh dipertingkatkan, kerana ia hanya boleh dibekalkan seberapa banyak yang diperlukan. Nah, satu-satunya negatif ialah kami telah kehilangan ketersediaan tinggi untuk pengguna luaran. Tetapi pada masa itu kami terpaksa mengorbankan ini, kerana ia perlu untuk menyelesaikan masalah dengan segera. Jadi, kami mengalih keluar sebahagian daripada beban itu, kira-kira 40% pada masa itu, LTM berasa baik, dan dua minggu selepas masalah bermula, kami mula menghantar bukan 45k permintaan sesaat, tetapi 55k. Malah, kami meningkat sebanyak 20% - ini jelas trafik yang tidak kami berikan kepada pengguna. Dan selepas itu mereka mula berfikir tentang cara menyelesaikan masalah yang tinggal - untuk memastikan kebolehcapaian luaran yang tinggi.
Kami mempunyai beberapa jeda, di mana kami membincangkan penyelesaian yang akan kami gunakan untuk ini. Terdapat cadangan untuk memastikan kebolehpercayaan menggunakan DNS, dengan bantuan beberapa skrip yang ditulis di rumah, protokol penghalaan dinamik... terdapat banyak pilihan, tetapi sudah menjadi jelas bahawa untuk penghantaran foto yang benar-benar boleh dipercayai, anda perlu memperkenalkan lapisan lain yang akan memantau ini. Kami memanggil pengarah foto mesin ini. Perisian yang kami andalkan ialah Keepalived:
Sebagai permulaan, apakah kandungan Keepalived? Yang pertama ialah protokol VRRP, yang dikenali secara meluas kepada perangkaian, terletak pada peralatan rangkaian yang memberikan toleransi kesalahan kepada alamat IP luaran yang disambungkan oleh pelanggan. Bahagian kedua ialah IPVS, pelayan maya IP, untuk mengimbangi antara penghala foto dan memastikan toleransi kesalahan pada tahap ini. Dan ketiga - pemeriksaan kesihatan.
Mari kita mulakan dengan bahagian pertama: VRRP - bagaimana rupanya? Terdapat IP maya tertentu, yang mempunyai entri dalam dns badoocdn.com, tempat pelanggan menyambung. Pada satu ketika, kami mempunyai alamat IP pada satu pelayan. Paket Keepalived dijalankan antara pelayan melalui protokol VRRP, dan jika induk hilang daripada radar - pelayan telah but semula atau sesuatu yang lain, pelayan sandaran secara automatik mengambil alamat IP ini - tiada tindakan manual diperlukan. Perbezaan antara induk dan sandaran adalah keutamaan terutamanya: semakin tinggi ia, semakin besar peluang mesin itu akan menjadi induk. Kelebihan yang sangat besar ialah anda tidak perlu mengkonfigurasi alamat IP pada pelayan itu sendiri, cukup untuk menerangkannya dalam konfigurasi, dan jika alamat IP memerlukan beberapa peraturan penghalaan tersuai, ini diterangkan secara langsung dalam konfigurasi, menggunakan sintaks yang sama seperti yang diterangkan dalam pakej VRRP. Anda tidak akan menemui apa-apa perkara yang tidak dikenali.
Apakah rupa ini dalam amalan? Apa yang berlaku jika salah satu pelayan gagal? Sebaik sahaja tuan hilang, sandaran kami berhenti menerima iklan dan secara automatik menjadi tuan. Selepas beberapa lama, kami membaiki induk, but semula, menaikkan Keepalived - iklan tiba dengan keutamaan yang lebih tinggi daripada sandaran, dan sandaran secara automatik berpatah balik, mengalih keluar alamat IP, tiada tindakan manual perlu dilakukan.
Oleh itu, kami telah memastikan toleransi kesalahan alamat IP luaran. Bahagian seterusnya adalah untuk mengimbangi trafik dari alamat IP luaran ke penghala foto yang sudah menamatkannya. Semuanya agak jelas dengan protokol pengimbangan. Ini sama ada round-robin mudah, atau perkara yang sedikit lebih kompleks, wrr, sambungan senarai dan sebagainya. Ini pada dasarnya diterangkan dalam dokumentasi, tidak ada yang istimewa. Tetapi kaedah penyampaian... Di sini kita akan melihat dengan lebih dekat mengapa kami memilih salah satu daripadanya. Ini ialah NAT, Penghalaan Terus dan TUN. Hakikatnya ialah kami segera merancang untuk menyampaikan 100 gigabit trafik dari tapak. Jika anda anggaran, anda memerlukan 10 kad gigabit, bukan? 10 kad gigabit dalam satu pelayan sudah berada di luar skop, sekurang-kurangnya, konsep "peralatan standard" kami. Dan kemudian kami teringat bahawa kami bukan hanya memberikan sedikit lalu lintas, kami memberikan foto.
Apa yang istimewa? β Perbezaan besar antara trafik masuk dan keluar. Trafik masuk sangat kecil, trafik keluar sangat besar:
Jika anda melihat graf ini, anda dapat melihat bahawa pada masa ini pengarah menerima kira-kira 200 MB sesaat, ini adalah hari yang sangat biasa. Kami memberikan kembali 4,500 MB sesaat, nisbah kami adalah lebih kurang 1/22. Sudah jelas bahawa untuk menyediakan trafik keluar sepenuhnya kepada 22 pelayan pekerja, kami hanya memerlukan satu yang menerima sambungan ini. Di sinilah algoritma penghalaan terus membantu kami.
Bagaimana rupanya? Pengarah foto kami, mengikut jadualnya, menghantar sambungan ke penghala foto. Tetapi penghala foto menghantar trafik balik terus ke Internet, menghantarnya kepada pelanggan, ia tidak kembali melalui pengarah foto, oleh itu, dengan bilangan mesin yang minimum, kami memastikan toleransi kesalahan lengkap dan mengepam semua lalu lintas. Dalam konfigurasi ia kelihatan seperti ini: kami menentukan algoritma, dalam kes kami ia adalah rr mudah, sediakan kaedah penghalaan terus dan kemudian mula menyenaraikan semua pelayan sebenar, berapa banyak daripada mereka yang kami ada. Yang akan menentukan trafik ini. Jika kami mempunyai satu atau dua lagi pelayan di sana, atau beberapa pelayan, keperluan seperti itu timbul - kami hanya menambah bahagian ini pada konfigurasi dan jangan terlalu risau. Dari sisi pelayan sebenar, dari sisi penghala foto, kaedah ini memerlukan konfigurasi yang paling minimum, ia diterangkan dengan sempurna dalam dokumentasi, dan tidak ada perangkap di sana.
Apa yang menarik ialah penyelesaian sedemikian tidak membayangkan reka bentuk semula radikal rangkaian tempatan; ini penting bagi kami; kami terpaksa menyelesaikannya dengan kos yang minimum. Jika anda melihat , maka kita akan lihat bagaimana rupanya. Di sini kita mempunyai pelayan maya tertentu, pada port 443, mendengar, menerima sambungan, semua pelayan yang berfungsi disenaraikan, dan anda boleh melihat bahawa sambungan itu, memberi atau menerima, sama. Jika kita melihat statistik pada pelayan maya yang sama, kita mempunyai paket masuk, sambungan masuk, tetapi sama sekali tidak ada yang keluar. Sambungan keluar pergi terus kepada pelanggan. Okay, kami dapat menyahseimbangkannya. Sekarang, apa yang berlaku jika salah satu penghala foto kami gagal? Lagipun, besi adalah besi. Ia mungkin menjadi panik kernel, ia mungkin pecah, bekalan kuasa mungkin terbakar. apa-apa sahaja. Itulah sebabnya pemeriksaan kesihatan diperlukan. Mereka boleh semudah menyemak cara port dibuka, atau sesuatu yang lebih kompleks, sehingga beberapa skrip yang ditulis di rumah yang akan menyemak logik perniagaan.
Kami berhenti di suatu tempat di tengah: kami mempunyai permintaan https ke lokasi tertentu, skrip dipanggil, jika ia bertindak balas dengan respons ke-200, kami percaya bahawa semuanya baik-baik saja dengan pelayan ini, bahawa ia masih hidup dan boleh dihidupkan dengan agak dengan mudah.
Bagaimanakah ini, sekali lagi, kelihatan dalam amalan? Mari matikan pelayan untuk penyelenggaraan - berkelip BIOS, sebagai contoh. Dalam log kami serta-merta mempunyai tamat masa, kami melihat baris pertama, kemudian selepas tiga percubaan ia ditandakan sebagai "gagal", dan ia hanya dialih keluar daripada senarai.
Pilihan tingkah laku kedua juga mungkin, apabila VS hanya ditetapkan kepada sifar, tetapi jika foto dikembalikan, ini tidak berfungsi dengan baik. Pelayan muncul, Nginx bermula di sana, pemeriksaan kesihatan segera memahami bahawa sambungan berfungsi, semuanya baik-baik saja, dan pelayan muncul dalam senarai kami, dan beban serta-merta mula digunakan padanya. Tiada tindakan manual diperlukan daripada pentadbir tugas. Pelayan but semula pada waktu malam - jabatan pemantauan tidak menghubungi kami mengenai perkara ini pada waktu malam. Mereka memberitahu anda bahawa ini berlaku, semuanya baik-baik saja.
Jadi, dengan cara yang agak mudah, dengan bantuan sebilangan kecil pelayan, kami menyelesaikan masalah toleransi kesalahan luaran.
Apa yang perlu diperkatakan ialah semua ini, sudah tentu, perlu dipantau. Secara berasingan, perlu diperhatikan bahawa Keepalivede, sebagai perisian yang ditulis lama dahulu, mempunyai banyak cara untuk memantaunya, kedua-duanya menggunakan semakan melalui DBus, SMTP, SNMP dan Zabbix standard. Selain itu, dia sendiri tahu cara menulis surat untuk hampir setiap bersin, dan sejujurnya, pada satu ketika kami juga terfikir untuk mematikannya, kerana dia menulis banyak surat untuk sebarang penukaran trafik, menghidupkan, untuk setiap sambungan IP, dan seterusnya. Sudah tentu, jika terdapat banyak pelayan, maka anda boleh mengatasi diri anda dengan surat-surat ini. Kami memantau nginx pada penghala foto menggunakan kaedah standard, dan pemantauan perkakasan tidak hilang. Kami, sudah tentu, akan menasihati dua lagi perkara: pertama, pemeriksaan kesihatan luaran dan ketersediaan, kerana walaupun semuanya berfungsi, sebenarnya, mungkin pengguna tidak menerima foto kerana masalah dengan pembekal luar atau sesuatu yang lebih kompleks. Ia sentiasa berbaloi untuk disimpan di suatu tempat di rangkaian lain, di Amazon atau di tempat lain, mesin berasingan yang boleh ping pelayan anda dari luar, dan ia juga berbaloi menggunakan pengesanan anomali, bagi mereka yang tahu cara melakukan pembelajaran mesin yang rumit, atau pemantauan mudah , sekurang-kurangnya untuk menjejak jika permintaan telah menurun secara mendadak, atau, sebaliknya, meningkat. Ia juga boleh berguna.
Mari kita ringkaskan: kami, sebenarnya, menggantikan penyelesaian berlapis besi, yang pada satu ketika tidak lagi sesuai dengan kami, dengan sistem yang agak mudah yang melakukan semua perkara yang sama, iaitu, ia menyediakan penamatan trafik HTTPS dan penghalaan pintar selanjutnya dengan pemeriksaan kesihatan yang diperlukan. Kami telah meningkatkan kestabilan sistem ini, iaitu, kami masih mempunyai ketersediaan yang tinggi untuk setiap lapisan, ditambah kami mendapat bonus bahawa ia agak mudah untuk menskalakan semuanya pada setiap lapisan, kerana ia adalah perkakasan standard dengan perisian standard, iaitu , kami telah memudahkan mendiagnosis masalah yang mungkin berlaku.
Apa yang telah kita lalui? Kami menghadapi masalah semasa cuti Januari 2018. Dalam enam bulan pertama semasa kami melaksanakan skim ini, kami mengembangkannya kepada semua trafik untuk mengalih keluar semua trafik daripada LTM, kami hanya meningkatkan trafik dalam satu pusat data daripada 40 gigabit kepada 60 gigabit, dan pada masa yang sama untuk sepanjang tahun 2018 dapat menghantar hampir tiga kali lebih banyak foto sesaat.
Sumber: www.habr.com