Penghujung bulan pertama dan awal bulan kedua musim panas 2019 ternyata sukar dan ditandai dengan beberapa kejatuhan besar dalam perkhidmatan IT global. Antara yang ketara: dua insiden serius dalam infrastruktur CloudFlare (yang pertama - dengan tangan bengkok dan sikap cuai terhadap BGP di pihak beberapa ISP dari Amerika Syarikat; yang kedua - dengan penggunaan CF yang bengkok sendiri, yang menjejaskan semua orang yang menggunakan CF , dan ini adalah banyak perkhidmatan ketara) dan operasi infrastruktur CDN Facebook yang tidak stabil (menjejaskan semua produk FB, termasuk Instagram dan WhatsApp). Kami juga terpaksa jatuh di bawah pengedaran, walaupun gangguan kami kurang ketara berbanding latar belakang global. Seseorang telah mula menyeret masuk helikopter hitam dan konspirasi "berdaulat", jadi kami mengeluarkan bedah siasat awam mengenai kejadian kami.
03.07.2019, 16: 05
Masalah dengan sumber mula direkodkan, sama seperti kerosakan dalam sambungan rangkaian dalaman. Setelah tidak menyemak semuanya sepenuhnya, mereka mula menyalahkan prestasi saluran luaran terhadap DataLine, kerana menjadi jelas bahawa masalahnya adalah dengan akses rangkaian dalaman ke Internet (NAT), sehingga meletakkan sesi BGP ke DataLine.
03.07.2019, 16: 35
Ia menjadi jelas bahawa peralatan yang menyediakan terjemahan alamat rangkaian dan akses daripada rangkaian tempatan tapak ke Internet (NAT) telah gagal. Percubaan untuk but semula peralatan tidak membawa apa-apa; pencarian untuk pilihan alternatif untuk mengatur sambungan bermula sebelum menerima respons daripada sokongan teknikal, kerana dari pengalaman, ini kemungkinan besar tidak akan membantu.
Masalahnya agak diburukkan oleh fakta bahawa peralatan ini juga menamatkan sambungan masuk pekerja VPN pelanggan, dan kerja pemulihan jauh menjadi lebih sukar untuk dijalankan.
03.07.2019, 16: 40
Kami cuba menghidupkan semula skim NAT sandaran sedia ada sebelum ini yang telah berfungsi dengan baik sebelum ini. Tetapi menjadi jelas bahawa beberapa pengubahsuaian rangkaian menjadikan skim ini hampir tidak berfungsi sepenuhnya, kerana pemulihannya boleh, paling baik, tidak berfungsi, atau, paling teruk, memecahkan apa yang telah berfungsi.
Kami mula mengusahakan beberapa idea untuk memindahkan trafik ke satu set penghala baharu yang berfungsi sebagai tulang belakang, tetapi ia kelihatan tidak dapat dilaksanakan kerana keanehan pengedaran laluan dalam rangkaian teras.
03.07.2019, 17: 05
Pada masa yang sama, masalah telah dikenal pasti dalam mekanisme penyelesaian nama pada pelayan nama, yang membawa kepada ralat dalam menyelesaikan titik akhir dalam aplikasi, dan mereka mula mengisi fail hos dengan cepat dengan rekod perkhidmatan kritikal.
03.07.2019, 17: 27
Fungsi terhad Habr telah dipulihkan.
03.07.2019, 17: 43
Tetapi pada akhirnya, penyelesaian yang agak selamat ditemui untuk mengatur lalu lintas melalui salah satu penghala sempadan, yang dipasang dengan cepat. Sambungan Internet telah dipulihkan.
Dalam beberapa minit seterusnya, banyak pemberitahuan datang daripada sistem pemantauan tentang pemulihan fungsi ejen pemantauan, tetapi beberapa perkhidmatan ternyata tidak boleh beroperasi kerana mekanisme resolusi nama pada pelayan nama (dns) telah rosak.
03.07.2019, 17: 52
NS telah dimulakan semula dan cache telah dibersihkan. Penyelesaian telah dipulihkan.
03.07.2019, 17: 55
Semua perkhidmatan mula berfungsi kecuali MK, Freelansim dan Toaster.
03.07.2019, 18: 02
MK dan Freelansim mula bekerja.
03.07.2019, 18: 07
Kembalikan sesi BGP yang tidak bersalah dengan DataLine.
03.07.2019, 18: 25
Mereka mula merekodkan masalah dengan sumber, yang disebabkan oleh perubahan dalam alamat luaran kumpulan NAT dan ketiadaannya dalam acl beberapa perkhidmatan, yang telah diperbetulkan dengan segera. Pembakar roti mula berfungsi serta-merta.
03.07.2019, 20: 30
Kami melihat ralat yang berkaitan dengan bot Telegram. Ternyata mereka terlupa untuk mendaftarkan alamat luaran dalam beberapa acl (pelayan proksi), yang telah diperbetulkan dengan segera.
Penemuan
- Peralatan yang sebelum ini menimbulkan keraguan tentang kesesuaiannya, gagal. Terdapat rancangan untuk menghapuskannya dari kerja, kerana ia mengganggu pembangunan rangkaian dan mempunyai masalah keserasian, tetapi pada masa yang sama ia menjalankan fungsi kritikal, itulah sebabnya sebarang penggantian secara teknikal sukar tanpa mengganggu perkhidmatan. Sekarang anda boleh meneruskan.
- Isu DNS boleh dielakkan dengan mengalihkannya lebih dekat ke rangkaian tulang belakang baharu di luar rangkaian NAT dan masih mempunyai sambungan penuh ke rangkaian kelabu tanpa terjemahan (iaitu rancangan sebelum kejadian).
- Anda tidak sepatutnya menggunakan nama domain semasa memasang kluster RDBMS, kerana kemudahan menukar alamat IP secara telus tidak begitu diperlukan, kerana manipulasi sedemikian masih memerlukan pembinaan semula kluster. Keputusan ini ditentukan oleh sebab sejarah dan, pertama sekali, oleh kejelasan titik akhir mengikut nama dalam konfigurasi RDBMS. Secara umum, perangkap klasik.
- Pada dasarnya, latihan yang setanding dengan "kedaulatan Runet" telah dijalankan; ada sesuatu yang perlu difikirkan dari segi mengukuhkan keupayaan kelangsungan hidup autonomi.
Sumber: www.habr.com