Biasanya tidak lazim untuk membicarakan kesalahan seperti itu, karena hanya orang surgawi yang tidak berdosa yang bekerja di semua integrator. Seperti yang Anda ketahui, pada tingkat DNA, tidak ada kemungkinan salah atau salah.
Tapi saya akan mengambil risiko itu. Saya berharap pengalaman saya bermanfaat bagi seseorang. Kami memiliki satu pelanggan utama, retail online, yang kami dukung penuh dengan pabrik Cisco ACI. Perusahaan tidak memiliki administrator yang kompeten untuk sistem ini. Fabric jaringan adalah sekelompok sakelar yang memiliki pusat kendali tunggal. Plus, ada banyak fitur berguna yang sangat dibanggakan oleh pabrikan, tetapi pada akhirnya, untuk menghapus semuanya, Anda memerlukan satu admin, bukan lusinan. Dan satu pusat kendali, bukan lusinan konsol.
Ceritanya dimulai seperti ini: pelanggan ingin mentransfer inti dari seluruh jaringan ke grup sakelar ini. Keputusan ini disebabkan oleh fakta bahwa arsitektur ACI, di mana kelompok sakelar ini "dikumpulkan", sangat toleran terhadap kesalahan. Meskipun ini tidak umum dan secara umum, pabrik di pusat data mana pun tidak digunakan sebagai jaringan transit untuk jaringan lain dan hanya berfungsi untuk menghubungkan beban akhir (jaringan rintisan). Tetapi pendekatan seperti itu sangat mungkin, jadi pelanggan ingin - kami melakukannya.
Kemudian hal yang dangkal terjadi - Saya bingung dua tombol: menghapus kebijakan dan menghapus konfigurasi fragmen jaringan:
Nah, kemudian, menurut klasik, perlu untuk memasang kembali bagian dari jaringan yang runtuh.
Dalam urutan
Permintaan pelanggan terdengar seperti ini: grup pelabuhan terpisah perlu dibangun untuk mentransfer peralatan langsung ke pabrik ini.
Rekan-rekan kerja, harap transfer pengaturan port Leaf 1-1 101 dan leaf 1-2 102, port 43 dan 44, ke Leaf 1-3 103 dan leaf 1-4 104, port 43 dan 44. Ke port 43 dan 44 di Leaf 1- 1 dan 1-2, tumpukan 3650 terhubung, belum dioperasikan, Anda dapat mentransfer pengaturan port kapan saja.
Artinya, mereka ingin mentransfer cluster server. Itu perlu untuk mengkonfigurasi grup port virtual baru untuk lingkungan server. Sebenarnya, ini adalah tugas rutin; biasanya tidak ada waktu henti layanan untuk tugas semacam itu. Intinya, grup port dalam terminologi APIC adalah VPC yang dirakit dari port yang secara fisik terletak di sakelar yang berbeda.
Masalahnya adalah bahwa di pabrik, pengaturan grup port ini terikat ke entitas terpisah (yang muncul karena fakta bahwa pabrik dikontrol dari pengontrol). Objek ini disebut kebijakan port. Artinya, ke grup port yang kami tambahkan, kami juga perlu menerapkan kebijakan umum dari atas sebagai entitas yang akan mengelola port tersebut.
Artinya, EPG mana yang digunakan pada port 43 dan 44 pada node 101 dan 102 perlu dianalisis untuk menyusun konfigurasi yang sama pada node 103-104. Setelah menganalisis perubahan yang diperlukan, saya mulai mengkonfigurasi node 103-104. Untuk mengonfigurasi VPC baru dalam kebijakan antarmuka yang ada untuk node 103 dan 104, perlu dibuat kebijakan di mana antarmuka 43 dan 44 akan digunakan.
Dan ada satu nuansa di GUI. Saya membuat kebijakan ini dan menyadari bahwa selama proses konfigurasi saya membuat kesalahan kecil - saya menamakannya berbeda dari kebiasaan pelanggan. Ini tidak penting - karena kebijakan tersebut baru dan tidak memengaruhi apa pun. Dan saya harus menghapus kebijakan ini, karena perubahan tidak dapat lagi dilakukan padanya (nama tidak berubah) - Anda hanya dapat menghapus dan membuat ulang kebijakan.
Masalahnya adalah GUI memiliki ikon hapus yang mengacu pada kebijakan antarmuka, dan ada ikon yang mengacu pada kebijakan sakelar. Secara visual, keduanya hampir identik. Dan alih-alih menghapus kebijakan yang saya buat, saya menghapus semua konfigurasi untuk antarmuka pada sakelar 103-104:
Alih-alih menghapus satu grup, saya sebenarnya menghapus semua VPC dari pengaturan node, menggunakan delete, bukan tempat sampah.
Tautan ini memiliki VLAN yang peka bisnis. Faktanya, setelah menghapus konfigurasi, saya menonaktifkan sebagian grid. Selain itu, ini tidak segera terlihat, karena pabrik tidak dikontrol melalui kernel, tetapi memiliki antarmuka manajemen terpisah. Saya tidak langsung diusir, tidak ada error di pabrik karena tindakan diambil oleh administrator. Dan antarmuka berpikir - yah, jika Anda mengatakan untuk menghapus, maka seharusnya begitu. Tidak ada indikasi kesalahan. Perangkat lunak memutuskan bahwa semacam konfigurasi ulang sedang berlangsung. Jika admin menghapus profil daun, maka untuk pabrik itu tidak ada lagi dan tidak menulis kesalahan yang menyatakan bahwa itu tidak berfungsi. Itu tidak berhasil - karena sengaja dihapus. Seharusnya tidak berfungsi untuk perangkat lunak.
Jadi perangkat lunak memutuskan bahwa saya adalah Chuck Norris dan tahu persis apa yang saya lakukan. Semuanya terkendali. Admin tidak mungkin salah, dan bahkan ketika dia menembak dirinya sendiri, ini adalah bagian dari rencana yang licik.
Tetapi setelah sekitar sepuluh menit saya dikeluarkan dari VPN, yang pada awalnya tidak saya kaitkan dengan konfigurasi APIC. Tapi ini setidaknya mencurigakan, dan saya menghubungi pelanggan untuk mengklarifikasi apa yang terjadi. Dan selama beberapa menit berikutnya, saya pikir masalahnya adalah pekerjaan teknis, ekskavator tiba-tiba atau listrik mati, tetapi bukan konfigurasi pabrik.
Jaringan pelanggan itu kompleks. Kami hanya melihat sebagian dari lingkungan dengan akses kami. Saat memulihkan peristiwa, semuanya tampak seperti penyeimbangan kembali lalu lintas telah dimulai, setelah itu, setelah beberapa detik, perutean dinamis dari sistem yang tersisa sama sekali tidak diambil.
VPN yang saya gunakan adalah VPN admin. Karyawan biasa duduk di sisi lain, semuanya terus bekerja untuk mereka.
Secara umum, butuh beberapa menit negosiasi untuk memahami bahwa masalahnya masih dalam konfigurasi saya. Tindakan pertama dalam pertempuran dalam situasi seperti ini adalah melakukan rollback ke konfigurasi sebelumnya, dan baru kemudian membaca log, karena ini adalah prod.
Restorasi pabrik
Butuh waktu 30 menit untuk memulihkan pabrik - termasuk semua panggilan dan mengumpulkan semua yang terlibat.
Kami menemukan VPN lain yang dapat Anda gunakan (ini memerlukan persetujuan dengan penjaga keamanan), dan saya membatalkan konfigurasi pabrik - di Cisco ACI, ini dilakukan dalam dua klik. Tidak ada yang rumit. Titik pemulihan hanya dipilih. Dibutuhkan 10-15 detik. Artinya, pemulihannya sendiri membutuhkan waktu 15 detik. Sisa waktu dihabiskan untuk mencari tahu cara mendapatkan remote control.
Setelah kejadian itu
Di hari lain kami mengurai log dan memulihkan rangkaian peristiwa. Kemudian mereka menelepon pelanggan, dengan tenang menyatakan esensi dan penyebab insiden tersebut, mengusulkan sejumlah tindakan untuk meminimalkan risiko situasi tersebut dan faktor manusia.
Kami sepakat bahwa kami hanya menyentuh konfigurasi pabrik selama bukan jam kerja: malam dan sore hari. Kami melakukan pekerjaan dengan koneksi jarak jauh duplikat (ada saluran VPN yang berfungsi, ada yang cadangan). Pelanggan menerima peringatan dari kami dan saat ini memantau layanan.
Insinyur (yaitu saya) tetap sama dalam proyek tersebut. Saya dapat mengatakan bahwa perasaan percaya pada saya telah menjadi lebih besar daripada sebelum kejadian - saya pikir, justru karena kami dengan cepat menangani situasi tersebut dan tidak membiarkan gelombang kepanikan menutupi pelanggan. Yang utama adalah mereka tidak mencoba menyembunyikan persendiannya. Dari praktik, saya tahu bahwa dalam situasi ini, paling mudah untuk mencoba beralih ke vendor.
Kami menerapkan kebijakan jaringan yang serupa untuk pelanggan outsourcing lainnya: lebih sulit bagi pelanggan (saluran VPN tambahan, perubahan admin tambahan selama jam istirahat), tetapi banyak yang mengerti mengapa hal ini perlu.
Kami juga menggali lebih dalam perangkat lunak Cisco Network Assurance Engine (NAE), di mana kami menemukan peluang untuk melakukan dua hal sederhana namun sangat penting di pabrik ACI:
- pertama, NAE memungkinkan kami menganalisis perubahan yang direncanakan, bahkan sebelum kami meluncurkannya ke pabrik dan memotret semuanya untuk diri kami sendiri, memprediksi bagaimana perubahan tersebut akan berdampak positif atau negatif pada konfigurasi yang ada;
- kedua, NAE, setelah perubahan, memungkinkan Anda mengukur suhu pabrik secara keseluruhan dan melihat bagaimana perubahan ini pada akhirnya memengaruhi kondisi kesehatannya.
Jika Anda tertarik dengan detail lebih lanjut - besok kami akan memiliki webinar tentang dapur internal dukungan teknis, kami akan memberi tahu Anda bagaimana semuanya bekerja dengan kami dan dengan vendor. Kami juga akan menganalisis kesalahan)