Halo, Habr! Berikut ini adalah transkripsi laporan oleh Evgeny
error2407 Bogomazov (insinyur R&D jaringan) dan Dmitry
h8r Shemonaev (kepala NOC) dari UPTIMEDAY sebelumnya. Video di akhir pos.
Hari ini kami ingin berbicara tentang masalah apa yang muncul ketika membangun jaringan siaran. Mengapa kita membahas hal ini dan apa yang kita lakukan di sana.
Di Qrator Labs, kami membangun jaringan siaran kami sendiri untuk menyelesaikan masalah khusus yang berbeda dengan yang ada pada operator telekomunikasi "biasa". Oleh karena itu, kami memiliki titik kehadiran di wilayah ini - kami hanya lupa menambahkan Rusia di sini. Dan ini berarti kita memiliki banyak cerita tentang bagaimana dan tidak boleh dilakukan. Hari ini kami akan berbagi dengan Anda beberapa dari mereka.
Apa yang akan kita sampaikan, mengingat topik ini awalnya banyak sekali? Pada awalnya, kami hanya ingin melakukan tanya jawab (pertanyaan dan jawaban), tetapi kami masih diminta untuk membaca laporan. Karena itu, jika kami tidak memberi tahu sesuatu, tetapi kami pasti tidak punya waktu, tangkap kami sesudahnya, di sela-sela.
Sebagai bagian dari yang direncanakan, kami akan mencoba berbicara tentang perbedaan antara menyeimbangkan menggunakan DNS dan BGP. Bagaimana memilih situs baru dan apa yang perlu Anda perhatikan untuk menghindari rasa sakit selanjutnya. Bagaimana mendukung semua ini dan seberapa banyak tugas sulit yang akan disampaikan Dmitry.
Untuk memulainya, mari kita tentukan seberapa familiar Anda dengan topik tersebut.
- Berapa banyak yang tahu apa itu siaran dan mengapa itu dibutuhkan? (sekitar sepertiga tangan terangkat di aula)
- Dan siapa yang akrab dengan DNS dan mengkonfigurasi server? (tentang jumlah tangan yang sama)
- Dan BGP (dua tangan di bingkai)
Masih banyak.
- Nah, pertanyaan terakhir - siapa yang akrab dengan NOC? Siapa yang bermasalah dengan pemasok, dan siapa yang mencoba menyelesaikannya? (tangan administrator sistem Habr terlihat di bingkai)
Bagus Dalam hal ini, saya harap apa yang akan kami sampaikan kepada Anda muncul.
Sebelum pindah ke siaran mana pun, mari kita lihat mengapa itu diperlukan. Anda memiliki aplikasi untuk memproses permintaan pelanggan. Anda di-host di suatu tempat - sementara Anda tidak terlalu memikirkannya. Beli nama DNS, atasi, dan sebagainya. Kemudian tandatangani sertifikat, karena HTTPS. Aplikasi Anda berkembang.
Pertama, Anda harus menangani beban. Jika aplikasi Anda "menembak" pada saat yang sama - yaitu, aplikasi ini menjadi sangat populer, lebih banyak pengguna mendatangi Anda. Anda harus membeli besi dan menyeimbangkan beban di atasnya.
Selain itu, terutama pelanggan yang menuntut dapat muncul dengan kata-kata: "Guys, Anda harus selalu tersedia dan di mana saja untuk uang sebanyak itu!" Yang mengarah pada fakta bahwa Anda meletakkan redundansi sumber daya komputasi tidak hanya untuk pemrosesan beban puncak, tetapi hanya sebagai cadangan.
Selain itu, hari ini telah disebutkan dalam tampilan lain, Anda tidak dapat menempatkan kelenjar di satu pusat data - bencana alam dapat terjadi, yang berarti aplikasi akan mengalami downtime, yang akan menyebabkan kerugian finansial dan lainnya. Karena itu, jika aplikasi Anda telah berkembang dengan cukup, Anda seharusnya sudah berada di beberapa pusat data, jika tidak maka akan menjadi buruk.
Masalahnya memiliki sisi lain - jika aplikasi Anda sensitif terhadap waktu, seperti dalam analisis atau perdagangan keuangan, penting bagi Anda untuk mengirim permintaan kepada pengguna Anda secepat mungkin. Latensi terkenal dengan dua titik yang terhubung. Yang pertama - jika Anda ingin memberikan permintaan secepat mungkin, maka untuk ini jumlah permintaan dan tanggapan terhadap mereka harus sekecil mungkin. Sekali lagi, faktanya adalah ketika pengguna terhubung dengan Anda untuk pertama kalinya - semuanya tidak berfungsi dan ia dipaksa untuk melewati semua lingkaran neraka. Poin kedua adalah kecepatan cahaya. Paket dari Eropa Barat ke Rusia tidak bisa lebih cepat dari jumlah milidetik tertentu, tidak ada yang bisa dilakukan mengenai hal itu.
Perlu ditempatkan di beberapa pusat data karena kami ingin redundansi dan kami harus lebih dekat dengan pelanggan potensial. Jika, misalnya, wilayah klien utama Anda adalah Amerika, maka Anda akan menempatkan peralatan Anda di sana sehingga lalu lintas tidak melewati negara dan bagian dunia lainnya.
Ternyata dari titik tertentu Anda harus hadir di semua bagian dunia di tempat yang berbeda. Dan ini masih belum disiarkan.
Jadi, Anda memerlukan beberapa situs. Entah bagaimana Anda harus memilih mereka, keduanya awalnya baru, dan memahami kemampuan mereka untuk menskalakan - selama kelebihan, Anda harus membeli perangkat keras tambahan.
Jika Anda sudah memiliki beberapa situs, Anda perlu mempelajari cara mendistribusikan pengguna di antara mereka. Ada dua kursi: BGP dan DNS.
Dari dua poin kita akan mulai dengan yang terakhir. Dan lagi dua pendekatan utama. Pada awalnya, Anda memiliki situs yang berbeda, memiliki IP yang berbeda dan, karenanya, ketika pengguna membuat permintaan - ia mendapat IP dari situs tertentu dan memetakannya.
Apa yang kita putuskan di sini? Kami ingin pengguna dari wilayah tertentu untuk sampai ke situs yang terletak di wilayah yang sama. Solusi paling sederhana dan paling bodoh adalah menggunakan GeoDNS. Anda memiliki pemahaman tentang wilayah tempat awalan berada - Anda mengambil data ini, mendorongnya ke server DNS, memetakan pengguna yang sesuai, jika IP sumber berasal dari awalan yang tepat, ke situs yang tepat. Tapi ada masalah - penyelesai. Dan sekitar 15-20% permintaan berasal dari resolver - yaitu, sumber IP akan menjadi 8.8.8.8. Di mana harus meletakkan ini?
Untuk melakukan ini, ada EDNS, yang memungkinkan dalam kerangka permintaan untuk mentransfer subnet klien asli dari mana asalnya. Seperti yang Anda ketahui, pada tanggal 1 Februari 2019, Hari Bendera DNS terjadi - hanya sejak hari itu, semua server DNS harus mendukung ekstensi ini.
Dalam contoh ini, Anda dapat memiliki satu atau beberapa situs tempat server DNS berada yang memetakan pengguna - dan server itu sendiri dapat didistribusikan di seluruh dunia. Dan sudah dalam kerangka DNS ada kesempatan untuk menggunakan siaran - kami akan membicarakan hal ini sedikit kemudian.
Dalam skema umum, Anda memetakan pengguna ke situs yang paling dekat dengannya, memberikan alamat situs tertentu ini. Ini lebih jarang digunakan.
Pendekatan ketiga terkait dengan fakta bahwa bahkan jika pengguna berasal dari wilayah yang sama di mana situs tersebut berada, ini tidak berarti bahwa masalah keterlambatan telah diselesaikan. Mungkin lebih menguntungkan untuk mentransfer pengguna ke situs lain, karena wilayah tersebut dapat kelebihan beban jika ada rute alternatif. Apakah menyenangkan menggunakan ini? Sayangnya, hampir tidak ada solusi saat ini untuk melakukan hal serupa. Facebook entah bagaimana menunjukkan laporan bahwa ia melakukan ini - tetapi tidak ada kotak, semuanya harus dilakukan dengan tangan Anda sendiri.
Apa yang kita miliki dengan DNS?
Kelebihannya adalah bahwa pengguna yang berbeda dapat diberikan alamat yang berbeda, dan pengguna yang spesifik dapat dikirim ke situs yang didefinisikan secara ketat - yaitu, Anda dapat bekerja dengan pengguna individual. Yah, DNS mudah dikonfigurasi.
Apa kerugiannya? Jika Anda melakukan penyesuaian granular, maka konfigurasi tumbuh cukup cepat, yang tidak mungkin didukung dengan tangan Anda. Perlu otomatisasi. Dan jika otomasi dilakukan secara tidak benar, maka semuanya akan rusak - jika DNS terletak, maka aplikasi tidak dapat diakses.
Di sisi lain, jika Anda melakukan penyeimbangan DNS, maka pengguna akan memetakan ke situs tertentu dan IP-nya akan menjadi rentan. Ini adalah alasan mengapa kami tidak menggunakan DNS-balancing di rumah, karena dalam hal ini semua lalu lintas serangan dapat mengalir tepat pada satu titik, menonaktifkannya.
Dan seperti yang telah disebutkan, DNS tidak mendukung penyeimbangan latensi di luar kotak. Dan melakukannya sendiri sangat sulit.
Akhirnya mari kita ke hal-hal yang lebih baik, yaitu BGP anycast.
Ini persis kasus kami. Apa gunanya Semua situs memiliki IP yang sama, atau lebih tepatnya, mereka mengumumkan awalan yang sama. Pengguna memetakan ke situs "terdekat" dengannya. "Terdekat" dari sudut pandang BGP - awalan seperti itu diumumkan menggunakan berbagai rute, dan jika operator memiliki beberapa rute ke situs yang diiklankan, maka paling sering ia akan memilih yang terpendek. Lagi dari sudut pandang BGP. Kami akan segera menjelaskan mengapa ini buruk.
BGP juga berfungsi dengan ketersediaan awalan, sehingga Anda selalu beroperasi pada subnet dan tidak dapat memanipulasi masing-masing IP.
Akibatnya, karena awalan yang sama diumumkan dari semua situs, semua pengguna dari wilayah yang sama akan diarahkan ke situs yang sama. Penyerang tidak memiliki cara untuk mentransfer beban dari satu daerah ke daerah lain, jadi Anda perlu mendapatkan daya sebanyak di setiap tempat seperti operator yang memilih rute ini inginkan. Bahkan jika Anda tidak mencetak skor, itu masih dapat dilindungi.
Awalan yang sama diumumkan - apa yang bisa lebih mudah? Namun ada juga masalah.
Yang pertama adalah karena harus mengumumkan awalan yang sama di seluruh dunia, Anda terpaksa membeli alamat penyedia-independen, yang beberapa kali lebih mahal.
Yang kedua bermuara pada kenyataan bahwa pengguna dari satu wilayah tidak bisa begitu saja dilemparkan ke wilayah lain, jika tiba-tiba beberapa dari mereka tidak sah atau dengan tujuan mendiversifikasi lalu lintas serangan menggunakan situs lain, karena beberapa dari mereka terluka. Tidak ada pena seperti itu.
Masalah ketiga adalah bahwa dalam kerangka BGP sangat mudah untuk memilih situs "salah" dan penyedia "salah". Menurut Anda, Anda memiliki redundansi dan ketersediaan, tetapi pada kenyataannya tidak akan ada yang satu atau yang lain.
Anda memiliki beberapa situs tempat Anda ingin menyebarkan pengguna. Apa pegangan untuk membatasi wilayah tertentu, menarik pengguna ke situs tertentu?
Ada Komunitas Geo. Mengapa mereka Biarkan saya mengingatkan Anda - Anda memilih rute terdekat dari sudut pandang BGP. Dan Anda memiliki operator Tier-1, misalnya Level3, yang memiliki bagasi sendiri di seluruh dunia. Klien Level3, jika Anda terhubung langsung ke sana, terletak dalam dua harapan dari Anda. Dan beberapa operator lokal - dalam tiga. Oleh karena itu, operator dari Amerika akan lebih dekat dengan Anda daripada operator dari Rusia atau Eropa, karena dari sudut pandang BGP begitu.
Menggunakan Komunitas Geo, Anda dapat membatasi wilayah di mana operator besar dan internasional akan mengumumkan rute Anda. Masalahnya adalah bahwa mereka tidak selalu tersedia (Komunitas Geo).
Kami memiliki beberapa kasus ketika datang ke diri kita sendiri. Redup?
(Dmitry Shemonaev mengambil lantai)
Out of the box, banyak operator tidak menyediakan ini dan mengatakan bahwa, mereka berkata, kami tidak akan membatasi apa pun untuk netralitas jaringan, kebebasan, dan sebagainya. Kita harus menjelaskan kepada operator untuk waktu yang lama dan siapa kita, mengapa kita menginginkannya dan mengapa itu sangat penting bagi kita, dan juga untuk mendidik mengapa hal ini tidak berlaku untuk netralitas yang ada dalam pikiran mereka. Terkadang ini berhasil - dan kadang tidak, dan kami menolak untuk bekerja sama dengan operator yang berpotensi menarik karena kerja sama seperti itu akan menimbulkan rasa sakit lebih lanjut dalam pengoperasian layanan kami.
Juga, kita sering menemukan fakta bahwa ada sejumlah operator yang telah disebutkan oleh Eugene - ini adalah Tier-1, yang tidak membeli lalu lintas dari siapa pun dan hanya menukar lalu lintas di antara mereka. Tapi, selain mereka, ada beberapa dari setidaknya puluhan operator yang bukan Tier-1 - mereka membeli lalu lintas, tetapi pada saat yang sama mereka juga memiliki jaringan yang digunakan di seluruh dunia. Anda tidak perlu pergi jauh - dari yang terdekat dengan kami adalah Rostelecom atau ReTN, sedikit lebih jauh ada telekomunikasi Taipei yang indah, China Unicom, Singtel dan sebagainya.
Dan di Asia kita cukup sering menghadapi situasi sedemikian rupa sehingga, tampaknya, kita memiliki beberapa titik kehadiran di Asia, kita terhubung dengan beberapa operator yang agak besar, dari sudut pandang wilayah ini. Namun, kami terus dihadapkan dengan kenyataan bahwa lalu lintas dari Asia menuju situs kami melalui Eropa atau melakukan perjalanan Transatlantik. Dari sudut pandang BGP, ini cukup normal, karena tidak memperhitungkan latensi akun. Tetapi aplikasi menderita dalam kondisi seperti itu, penggunanya juga - secara umum, semua orang menderita, tetapi dari sudut pandang BGP, semuanya baik-baik saja.
Dan Anda harus membuat beberapa perubahan dengan tangan Anda, lakukan rekayasa balik tentang bagaimana pengaturan rute dari operator ini atau itu, kadang-kadang bernegosiasi, bertanya, memohon, berlutut. Secara umum, lakukan apa saja untuk menyelesaikan masalah ini. Dengan ini, NOC kami dihadapkan dengan keteraturan yang patut ditiru.
Sebagai aturan, operator memenuhi kebutuhan mereka dan dalam beberapa kasus siap untuk menyediakan satu set tertentu ... Tetapi secara umum, dapatkah mereka yang bekerja dengan BGP di tingkat masyarakat mengangkat tangan? (Tersenyum) Hebat! Artinya, operator siap untuk menyediakan beberapa set manajer komunitas agar, misalnya, untuk menurunkan preferensi lokal di wilayah tertentu, atau menambah prepend, atau tidak mengumumkan dengan baik atau sesuatu yang lain.
Oleh karena itu, ada dua cara untuk menyeimbangkan beban di BGP. Yang pertama adalah bagaimana ini ditulis pada slide, yang disebut prepends. Kita dapat membayangkan jalur ke BGP sebagai garis kecil yang mendaftarkan sistem otonom di mana jalur paket dari pengirim ke penerima lewat. Anda dapat menambahkan sejumlah sistem otonom ke jalur ini, dan sebagai hasilnya, jalur tersebut akan diperluas dan menjadi tidak terlalu prioritas. Ini adalah metode frontal dan tidak bekerja untuk semuanya - jika Anda menambahkan prepend, itu bukan granular, yaitu, semua orang akan melihatnya di kerucut operator di mana Anda melakukan manipulasi ini.
Di sisi lain, ada juga komunitas BGP, yang menandai komunitas tersebut, untuk memahami dari mana awalan ini atau itu, yang terkait dengan operator - yaitu, pesta, klien atau hulu, dan juga di tempat mana diambil dan begitu seterusnya. Dan ada manajer komunitas yang pergi ke router ke operator dan dia mengambil tindakan tertentu dengan awalan ini.
Sebagian besar operator memiliki komunitas terbatas. Ambil contoh operator Rusia abstrak, yang terhubung ke sejumlah operator Rusia dalam ruang hampa. Beberapa dari mereka memiliki hubungan peer-to-peer, yang menyiratkan pertukaran lalu lintas paritas, dan beberapa membelinya. Oleh karena itu, mereka menyediakan komunitas untuk membuat prepends ke arah ini, dengan memperluas jalur AS, atau tidak mengumumkan atau mengubah preferensi lokal. Jika Anda beroperasi dengan BGP - lihat komunitas dan pelajari apa yang dapat dilakukan pelamar untuk menjadi pemasok Anda. Terkadang komunitas disembunyikan dan Anda harus berkomunikasi dengan manajer operator atau dengan pakar teknis untuk menunjukkan kepada kami set tertentu yang didukung.
Secara default, komunitas, dalam hal wilayah Eropa, dijelaskan dalam RIPE DB. Artinya, Anda membuat permintaan untuk whois angka sistem otonom dan bidang Keterangan biasanya mengatakan apa yang dimiliki operator dalam hal menandai dan mengelola komunitas. Tidak semua orang memiliki ini, begitu sering Anda harus mencari tempat menarik yang berbeda.
Segera setelah Anda mulai mengoperasikan BGP, pada dasarnya, Anda mengatakan bahwa jaringan adalah bagian dari aplikasi Anda dan bukan sesuatu yang abstrak, sehingga Anda harus mempertimbangkan risikonya.
Misalnya, kami memiliki kasus dengan satu lembaga keuangan Latvia, yang awalannya, jika dimasukkan melalui jaringan kami, menjadi tidak tersedia di sekitar setengah dari Latvia. Meskipun tampaknya tidak ada yang berubah - awalan yang sama dengan yang kami umumkan di operator Tier-1, di Eropa, tampaknya semuanya ada di sana, termasuk redundansi. Tetapi kita bahkan tidak dapat membayangkan bahwa sekitar setengah dari operator Latvia memiliki perangkat perbatasan sehingga mereka tidak dapat mencerna volume penuh tampilan penuh (seluruh tabel perutean BGP), yang pada waktu itu adalah sekitar 650 ribu awalan. Mereka berdiri di sana, jika ada yang tahu apa itu Catalyst 3550, di sanalah ia berdiri, itu hanya bisa 12.000 awalan. Yah, mereka mendapat sejumlah awalan dari IX'a, yang, tentu saja, tidak ada default. Seiring dengan ini, dari operator lain - televisi Latvia, awalan di IX yang bukan / 24, tapi / 22 di mana ini / 24 berdiri.
Akibatnya, dia pergi ke tempat di mana dia tidak tahu ke mana harus mengarahkannya dan semuanya terbang ke pipa. Untuk memperbaikinya, kami memerlukan waktu sekitar dua hari dan korespondensi terus-menerus dengan operator Latvia sampai mereka menunjukkan kepada kami output dari perangkat perbatasan mereka dan kami hanya memperhatikan nama host di sana. Halo semuanya, terkadang sangat menyenangkan.
Ada banyak operator dengan besi tua. Ada banyak operator dengan pemahaman aneh tentang bagaimana jaringan seharusnya bekerja. Dan sekarang ini juga masalah Anda jika Anda akan bermain dengan BGP. Nah, pada akhirnya, banyak operator yang berkaki satu (satu penyedia konektivitas unggul), sehingga mereka memiliki set kruk sendiri.
(Evgeny Bogomazov melanjutkan)
Seperti yang Anda lihat, bahkan topik ini dapat dikembangkan untuk waktu yang lama dan sulit untuk disimpan dalam waktu 40 menit.
Jadi, Anda memiliki pena yang ingin Anda batasi wilayah tersebut. Sekarang mari kita mencari tahu apa yang perlu Anda perhatikan dan apa yang penting untuk dipertimbangkan ketika Anda ingin mengakomodasi di situs baru.
Kasus terbaik adalah tidak membeli perangkat keras Anda, tetapi setuju dengan cloud di hosting.
Maka sudah, akan mungkin untuk setuju dengannya bahwa Anda akan terhubung secara independen ke penyedia tertentu.Di sisi lain, jika Anda tetap menyusuri jalan ini, Anda harus secara kasar memahami wilayah mana, dengan atau tanpa pegangan, yang akan ditarik bersama ke situs ini. Untuk melakukan ini, Anda perlu pemodelan, atau lebih tepatnya, Anda perlu memahami bahwa jika ada beberapa rute dari situs yang berbeda, mana yang akan dipilih sebagai yang terbaik. Untuk melakukan ini, Anda harus memiliki beberapa gagasan tentang bagaimana BGP bekerja dan bagaimana rute bersirkulasi dalam situasi saat ini.Dua titik utama adalah panjang jalan, dipengaruhi oleh prepends dan preferensi lokal, yang mengatakan bahwa rute dari klien lebih disukai daripada rute dari tempat lain. Pada prinsipnya, kedua poin ini cukup untuk memahami wilayah mana yang akan disatukan dan di mana harus bangun.Antara lain, Anda perlu mempertimbangkan beberapa hal, yaitu, seperti apa konektivitas yang dimiliki pemasok Anda, dan juga fakta bahwa beberapa pemasok tidak berkomunikasi satu sama lain (perang peer-to-peer) dan bahkan jika Anda terhubung ke Tier-1 regional, ini tidak berarti bahwa semua pengguna lokal akan melihat Anda.Hal lain yang sering dilupakan adalah bahwa konektivitas di IPv4 dan IPv6 benar-benar berbeda, tidak portabel satu sama lain.
Dan di sini kita sampai pada poin utama. Menjawab pertanyaan: "Di mana harus bangun?" pilihannya tampak jelas. Jika Anda memiliki pengguna di wilayah tersebut, Anda mencapai IX di wilayah ini dan tidak ada lagi yang perlu dipikirkan. Ada konektivitas, sebagian besar pengguna, secara teori, harus terhubung dengannya, dan sebagian besar spesialis konten, perusahaan seperti Yandex dan lainnya, pertama-tama terhubung ke IX dan baru kemudian ke pemasok. Tetapi pemasok mungkin memiliki pelanggan unik, beberapa pemasok sendiri tidak hadir di IX, dan akibatnya, Anda tidak dapat mengarahkan ulang pengguna ini ke diri Anda sendiri - mereka akan mendatangi Anda dengan cara yang aneh.Saat memilih pemasok, Anda tidak dapat mematikan kepala Anda - kami memiliki beberapa kasus ketika pendekatan yang salah menyebabkan masalah. Pemasok adalah pilihan kami, karena jika Anda tidak memiliki banyak sumber daya untuk menghubungkan, maka pergi ke pemain regional terbesar Anda akan berakhir dengan konektivitas yang sama seperti pada IX.Katakan padaku bagaimana memilih pemasok yang tepat, Dima.(dan lagi Dmitry Shemonaev)Oke. Mari kita bayangkan bahwa kita memiliki satu poin dan wilayah yang kita minati adalah Rusia. Kami memiliki titik dalam pusat data yang baik secara kondisional di Moskow, kami beroperasi dengan sistem otonom kami sendiri, serangkaian awalan kami sendiri dan memutuskan untuk skala menggunakan BGP anycast - bergaya dan modis.Bisnis, bersama dengan rekan-rekan teknis, memutuskan bahwa dari Vladivostok ke Moskow ada RTT yang sangat besar dan ini buruk, itu tidak baik. Katakanlah, kita akan tinggal di Moskow dan mengakhiri Novosibirsk, semuanya akan lebih baik, RTT akan jatuh, tentu saja. Tidak lebih cepat dikatakan daripada dilakukan.Ini menimbulkan pertanyaan tentang situs untuk peralatan, tetapi ini sedikit di luar ruang lingkup pembicaraan kami hari ini, tetapi pertanyaan memilih operator cukup.Tampaknya pilihannya sudah jelas - di Moskow kita terhubung ke Moskvatelekom bersyarat, mari kita berpegang teguh pada Novosibirsk juga. Ya, pada prinsipnya, kami dapat mengandalkan rute internal penyedia, tetapi ini tidak selalu benar - dalam hal ini kami menempatkan semua telur dalam satu keranjang dan kami harus memahami bahwa perutean sesuai dengan IGP operator mungkin tidak optimal, untuk sedikitnya, karena tidak selalu jelas. apa yang mendorongnya. Terkadang itu bisa dimengerti, terkadang tidak terlalu - sekarang ini bukan tentang itu, selain itu, manajemen melarang saya untuk bersumpah, jadi saya tidak bisa melihat beberapa contoh secara detail.Tren modern sedemikian rupa sehingga bahkan Moskvatelecom dapat mengatakan bahwa saatnya telah tiba untuk SDN dan sekarang kita akan meletakkan pengontrol yang luar biasa yang akan mengendalikan jaringan. Dan pada satu titik, pengontrol seperti itu dapat menghancurkan jaringan ini. Begitu saja saya tidak ingat kasus seperti itu, khususnya dengan pengontrol SDN, tetapi baru-baru ini di Amerika, operator besar (CenturyLink) meninggalkan satu kartu jaringan ke dewa jaringan dan seluruh jaringan tidak stabil di seluruh Amerika Serikat. Karena satu kartu antarmuka jaringan. NOC dari operator ini menyelesaikan masalah ini selama tiga atau empat hari. Karena satu kartu jaringan.Jika Anda terhubung ke satu operator - saya dengan tulus mengucapkan selamat kepada Anda.Nah, kemudian mereka telah memutuskan - kami tidak akan bekerja sama dengan operator tunggal bersyarat di Moskow dan Novosibirsk. Di sini - dengan Moskvatelecom, dan di sana - dengan Novosibirsktelecom (semua kebetulan adalah acak). Ukuran kerucut klien dari dua telekomunikasi ini berbeda seperti kura-kura dari gajah, dan Anda akan mendapatkan semua lalu lintas Anda ke tempat kerucut klien utama jatuh, yaitu ke Moskvatelecom yang berbasis di Moskow. Itu selalu disarankan bahwa operator adalah paritas dan memiliki rekan di antara mereka sendiri di wilayah wilayah di mana minat Anda berada. Di Rusia, beberapa tahun lalu, operator terbesar, seperti Rostelecom dan TTK, memiliki peering di Moskow, St. Petersburg, Nizhny Novgorod, Novosibirsk dan, tampaknya, di Vladivostok. Karena itu, lalu lintas berjalan antara operator ini plus atau minus secara optimal.Tetapi operator masih harus dipilih dengan benar. Jadi dia punya komunitas, jadi dia punya NOC. Semua ini sangat penting, karena tahun lalu ada kasus yang luar biasa ketika satu, operator Rusia yang cukup besar menguji beberapa layanannya dan pada malam hari ia mengumumkan banyak awalan dari kota St. Petersburg dengan memasukkan sistem otonomnya di server rute kedua. DE-CIX di Frankfurt. Dia mengumumkannya di sana dengan komunitas blackhole.Akibatnya, banyak operator dan pusat data St. Petersburg menghadapi ketidakmampuan mengakses dari, misalnya, jaringan TTK. Ini juga memengaruhi kami, tetapi kami dapat menyiasatinya, karena di antara titik-titik kami, kami memiliki jaringan sendiri, overlay di suatu tempat, dan di suatu tempat secara fisik, dan kami mengalihkan lalu lintas dari operator yang bermasalah ke yang tidak ada masalah. Secara umum, teratasi. Tetapi saya memberi tahu Anda hal ini agar Anda tahu bahwa NOC operator harus memadai, karena dalam kasus itu NOC pelaku tidak menghubungi pada malam Jumat hingga Sabtu, tetapi hanya bangun pada hari Senin. Tidak dapat diaksesnya parsial tiga hari untuk sejumlah operator. Lebih baik pikirkan tiga kali.
Ayo kembali ke NOC. Network Operations Center - pusat manajemen jaringan, ini adalah divisi dari perusahaan yang bergerak dalam pengoperasian jaringan, operasi jaringan, dan sebagainya. Jawaban untuk sejumlah tiket yang diterima mengenai jaringan. Apa yang ingin Anda tambahkan? Para spesialis yang dibesarkan di Aichi-sum di ruangan ini mungkin tahu semua hal baik tentang pemantauan. Ini sangat penting. Dalam beberapa kasus, hal-hal yang sangat spesifik harus dipantau.
Beberapa pengguna mungkin mengeluh bahwa "semuanya entah bagaimana buruk" dan tidak dapat memberikan diagnosa yang diperlukan untuk mulai bekerja untuk memperbaiki situasi. Ada sinyal yang buruk - dan apa dan di mana tidak jelas. Dalam hal ini, kami mencoba berinteraksi dengan NOC operator di kerucut klien tempat pengguna ini berada. Jika tidak berhasil, maka kami melihat korelasi apa yang ada - kemungkinan simpul proyek Atlas RIPE di dalam kerucut ini. Secara umum, kami mengumpulkan sebanyak yang kami bisa. Kami siap untuk apa yang tidak selalu dapat mereka berikan kepada kami.Dalam beberapa kasus, masuk akal untuk memantau dengan komunitas mana awalan ini atau itu datang ke router perbatasan Anda dan mengumpulkan retrospektif historis, maaf untuk tautologi. Sebagai contoh, kami mengambil tiga operator: Megafon, Rostelecom dan Transtelecom. Misalkan mereka semua mengintip di wilayah Federasi Rusia, dan Anda terhubung ke Rostelecom bersyarat atau itu tidak masalah. Anda melihat awalan di mana pengguna Anda berada, dengan semacam komunitas penandaan, dalam hal ini. Mereka dapat dikumpulkan, direkam, dan ketika sesuatu terjadi - komunitas akan berubah. Misalnya, Anda mendapatkan awalan dengan komunitas bahwa ini adalah pesta di Rusia. Ya, sudah direkam. Dan kemudian komunitas ini telah berubah menjadi kenyataan bahwa ini adalah pesta di Frankfurt. Apa artinya ini?
Bahwa operator ini memutuskan hubungan peer-to-peer dan Anda dan Latency tidak melakukannya dengan baik - Anda akan melalui loop Eropa. Dalam hal ini, Anda dapat melakukan sesuatu secara proaktif, tetapi itu memakan waktu dan membutuhkan tekad, serta kualitas lainnya.Dan jika mungkin, mengotomatiskan segalanya - itu sulit 10 tahun yang lalu, dan sekarang ada banyak utilitas, seperti Ansible, Chef, Puppet, yang dapat berinteraksi dengan elemen jaringan. Mengapa otomasi penting? Saya telah mengatur BGP untuk waktu yang sangat lama dan aturan pertama adalah sesuatu seperti ini: "Siapa pun yang mengatur lingkungan BGP Anda, di sisi lain, Anda tidak diatur oleh orang yang sangat baik." Dari sudut pandang orang itu, aturan ini juga berlaku untuk Anda.Saya pribadi memiliki kasus ketika saya mentransfer semua peer dari satu perbatasan ke perbatasan lain dalam operator Samara yang namanya tidak akan kami sebutkan. Saya memiliki persimpangan dengan satu penyedia konten utama - bioskop online dan saya memiliki persimpangan dengan putri lokal Rostelecom. Hanya dengan pengelola konten saya memiliki persimpangan gigabyte, dan dengan putri saya seratus gigabyte. Dan saya, sebagai orang yang menyenangkan, menanggung semua ini di malam hari - saya melihat grafik, pada sambungan seratus megabit dan berpikir: "Oh, betapa-apaan!" Dan kemudian saya melihat - ini di resimen, yang di resimen dan saya pikir (memukul dahi saya) - Saya lupa membuat filter. Itu harus dipagari dari tindakan mereka, karena semua orang menerima, dari serangan tiga kali lipat hanya perlu dilindungi oleh otomatisasi. Otomasi adalah musuh orang jahat dan teman orang baik.Maka Anda, Zhenya.
(Evgeny Bogomazov melanjutkan)Jadi kami membahas semua poin awal. Tetapi pada siaran mana pun, semuanya tidak berakhir, selain dia, Anda perlu melacak hal-hal lain yang tambahan.
Mari kita lihat apa lagi. Anda perlu melihat seberapa baik aplikasi terintegrasi ke dalam distribusi - jika ada beberapa situs, Anda harus dapat menyebarkan konten di situs-situs ini. Jika ini tidak memungkinkan, maka tidak masalah bagaimana sistem Anda didistribusikan, semua pengguna akan pergi ke situs di mana aplikasi itu sebenarnya berada. Dan tepatnya RTT Anda tidak akan menghemat.Di sisi lain, jika Anda tidak memiliki data pengguna seperti itu, maka Anda dapat menempatkan aplikasi pengguna di situs itu - lakukan saja. Jika aplikasi akan mendukung semuanya, maka gunakan cloud siaran, jika Anda tidak ingin mengembangkan infrastruktur Anda sendiri, ini akan membawa banyak keuntungan.Nah, jika Anda sudah memiliki beberapa situs dan pengguna datang ke salah satu dari mereka, sesuatu dapat terjadi di sana, katakanlah itu akan jatuh atau tautan akan rusak, sehingga pengguna akan pergi ke situs lain. Tapi mereka seharusnya tidak memperhatikannya. Oleh karena itu, Anda harus dapat mentransfer lalu lintas ini secepat mungkin dalam jaringan internal anycast, dan secara umum, Anda harus menganggap masalah ini sebagai hal yang tidak terhindarkan - oleh karena itu, menyenangkan untuk memasukkan sesuatu ke dalam aplikasi untuk mempersiapkan perkembangan acara.Idealnya, jika Anda memiliki metrik bisnis aplikasi, maka jika jatuh, segera buat permintaan pemantauan jaringan dan buat laporan tentang status jaringan internal atau eksternal, atau lebih baik keduanya. Metrik bisnis biasanya jatuh karena sesuatu terjadi di suatu tempat, tetapi ini, tentu saja, adalah utopia - bahkan kita belum mendekati ini.
Anda memiliki jaringan eksternal, tetapi ada juga situs internal - mereka harus berkomunikasi satu sama lain. Pada saat yang sama, Anda tidak perlu memiliki infrastruktur fisik sendiri - Anda dapat menggunakan jaringan operator pihak ketiga, yang utama adalah mengkonfigurasi terowongan virtual. Selain itu, Anda harus mengonfigurasi perutean jaringan internal, karena semuanya tidak berakhir pada BGP. Karena sifat pemrosesan lalu lintas, kami memiliki protokol, gaya komunikasi, dan skrip kami sendiri.Jika Anda memiliki beberapa situs, maka Anda harus dapat memperbarui konfigurasi di tempat yang berbeda secara bersamaan. Anda mendapatkan awalan baru - Anda harus mengumumkannya di mana-mana, memperbarui DNS - hal yang sama. Dalam konteks SDN, Anda harus mengumpulkan data dari situs dan mengumpulkannya di suatu tempat, dan menuangkan perubahan yang terjadi karena data ini kembali ke situs.
Item terakhir adalah DNS. Contoh dengan Dyn adalah indikatif - seperti yang Anda ingat, pada tahun 2016 sebuah serangan dilakukan terhadap mereka, yang tidak dapat mereka atasi dan sejumlah besar sumber daya populer di AS tidak lagi tersedia. DNS juga perlu dilindungi, jika tidak, pengguna tidak akan menemukan aplikasi Anda di jaringan. Tembolok DNS menyimpan, sebagian, dan ada pekerjaan yang menarik pada topik ini di IETF, tetapi selalu tergantung pada apakah resolver DNS tertentu akan mendukungnya.Bagaimanapun, Anda harus memiliki DNS yang aman. Ini adalah tahap pertama yang harus dikerjakan agar pengguna membiasakan diri dengan aplikasi Anda. Saat Anda membuka halaman untuk pertama kalinya, selain RTT, yang telah kami sebutkan, akan ada penundaan tambahan untuk permintaan DNS dan Anda harus siap bahwa untuk pertama kalinya halaman pengguna akan terbuka untuk waktu yang lama, seseorang mungkin tidak mentolerirnya. Jika bagi Anda penemuan pertama yang panjang sangat penting, Anda juga harus mempercepat DNS.Dalam hal siaran apa pun, Anda dapat menyimpan tanggapan DNS di tempat kehadiran Anda, karena Anda sudah memiliki situs-situs ini dan jawaban DNS akan datang dengan cukup cepat.
Apa masalahnya? Nah, latensi, baik, menyeimbangkan.Seperti yang telah kami sebutkan, masih ada alam. Sebagian karena itu, Anda perlu ditempatkan di tempat yang berbeda. Ini tidak boleh dilupakan, meskipun risikonya kecil.Ada juga seseorang dan faktor peluang. Karena itu, Anda harus mengotomatiskan semuanya sebanyak mungkin, menguji konfigurasi yang dituangkan dan memantau perubahannya. Bahkan jika Anda telah mengambil sesuatu, akan baik jika Anda dapat membuat perubahan dengan cepat dan lokal.Ini adalah 90% kasus. Tetapi 10% sisanya - ini adalah jika pesaing memutuskan untuk menghilangkan Anda. Dalam hal ini, Anda memiliki masalah serius. Mengapa "Reservasi" disorot dalam font besar yang terpisah? Jika Anda memutuskan untuk memasang, Anda akan membutuhkan sejumlah besar saluran di situs Anda, yang berarti Anda harus bernegosiasi dengan sejumlah besar penyedia. Jika tidak, dengan tingkat serangan rata-rata saat ini, Anda tidak dapat melakukannya sama sekali.
Jadi lebih baik mendelegasikan daripada membeli perangkat keras Anda sendiri. Bahkan bagian dari fungsi yang kami jelaskan hari ini dalam kerangka siaran dan masalah yang muncul mudah untuk dipecahkan secara salah. Jadi jika ada peluang untuk tidak menyelesaikan masalah ini dan mengalihkannya ke pihak luar, ini mungkin layak dilakukan. Jika tidak, Anda perlu menjawab pertanyaan mengapa Anda perlu menerapkan semua ini secara akurat.Nah, jika terjadi serangan, beralihlah ke awan yang berspesialisasi dalam memecahkan masalah seperti itu. Baik, atau Anda masih dapat mengobrol dengan kami.Terima kasih
Pertanyaan?