Struktur jaringan untuk pusat data Cisco ACI - untuk membantu administrator

Struktur jaringan untuk pusat data Cisco ACI - untuk membantu administrator
Dengan bantuan skrip Cisco ACI yang ajaib ini, Anda dapat mengatur jaringan dengan cepat.

Pabrik jaringan untuk pusat data Cisco ACI telah ada selama lima tahun, tetapi HabrΓ© tidak mengatakan apa-apa tentangnya, jadi saya memutuskan untuk memperbaikinya sedikit. Saya akan memberi tahu Anda dari pengalaman saya sendiri apa itu, apa gunanya dan di mana penggaruknya.

Apa itu dan dari mana asalnya?

Pada saat ACI (Application Centric Infrastructure) diumumkan pada tahun 2013, para pesaing menggunakan pendekatan tradisional untuk jaringan pusat data dari tiga sisi sekaligus.

Di satu sisi, solusi SDN "generasi pertama" berdasarkan OpenFlow berjanji untuk membuat jaringan lebih fleksibel dan lebih murah pada saat bersamaan. Idenya adalah untuk memindahkan pengambilan keputusan yang secara tradisional dilakukan oleh perangkat lunak sakelar berpemilik ke pengontrol pusat.

Pengontrol ini akan memiliki satu visi tentang segala sesuatu yang terjadi dan, berdasarkan ini, akan memprogram perangkat keras semua sakelar pada tingkat aturan untuk memproses aliran tertentu.
Di sisi lain, solusi jaringan overlay memungkinkan penerapan kebijakan konektivitas dan keamanan yang diperlukan tanpa perubahan apa pun dalam jaringan fisik sama sekali, membangun terowongan perangkat lunak di antara host tervirtualisasi. Contoh paling terkenal dari pendekatan ini adalah Nicira, yang saat itu telah diakuisisi oleh VMWare seharga $1,26 miliar dan melahirkan VMWare NSX saat ini. Beberapa hal yang menarik dari situasi ini ditambah dengan fakta bahwa para pendiri Nicira adalah orang yang sama yang sebelumnya berdiri di awal OpenFlow, sekarang mengatakan bahwa untuk membangun pabrik pusat data OpenFlow tidak cocok.

Dan akhirnya, chip switching yang tersedia di pasar terbuka (apa yang disebut silikon pedagang) telah mencapai tahap kedewasaan di mana mereka telah menjadi ancaman nyata bagi produsen switch tradisional. Jika sebelumnya setiap vendor secara mandiri mengembangkan chip untuk sakelarnya, maka seiring waktu, chip dari produsen pihak ketiga, terutama dari Broadcom, mulai mengurangi jarak dengan chip vendor dalam hal fungsi, dan mengungguli mereka dalam hal rasio harga / kinerja. Oleh karena itu, banyak yang percaya bahwa hari-hari sakelar pada chip desain mereka sendiri telah dihitung.

ACI telah menjadi "respons asimetris" Cisco (lebih tepatnya, perusahaan Insieme-nya, yang didirikan oleh mantan karyawannya) terhadap semua hal di atas.

Apa bedanya dengan OpenFlow?

Dalam hal pembagian fungsi, ACI sebenarnya kebalikan dari OpenFlow.
Dalam arsitektur OpenFlow, pengontrol bertanggung jawab untuk menulis aturan (aliran) terperinci
di perangkat keras semua sakelar, yaitu, di jaringan besar, ia mungkin bertanggung jawab untuk memelihara dan, yang paling penting, mengubah puluhan juta catatan di ratusan titik di jaringan, sehingga kinerja dan keandalannya menjadi hambatan dalam a implementasi besar.

ACI menggunakan pendekatan sebaliknya: tentu saja, ada juga pengontrol, tetapi sakelar menerima kebijakan deklaratif tingkat tinggi darinya, dan sakelar itu sendiri melakukan renderingnya menjadi detail pengaturan khusus di perangkat keras. Pengontrol dapat di-reboot atau dimatikan sama sekali, dan tidak ada hal buruk yang akan terjadi pada jaringan, kecuali, tentu saja, kurangnya kontrol saat ini. Menariknya, ada situasi di ACI di mana OpenFlow masih digunakan, tetapi secara lokal di dalam host untuk pemrograman Open vSwitch.

ACI dibangun sepenuhnya pada transpor overlay berbasis VXLAN, tetapi menyertakan transpor IP yang mendasarinya sebagai bagian dari solusi tunggal. Cisco menyebut ini istilah "overlay terintegrasi". Sebagai titik penghentian overlay di ACI, dalam banyak kasus, sakelar pabrik digunakan (mereka melakukan ini dengan kecepatan tautan). Tuan rumah tidak diharuskan untuk mengetahui apa pun tentang pabrik, enkapsulasi, dll. Namun, dalam beberapa kasus (misalnya, untuk menghubungkan host OpenStack), lalu lintas VXLAN dapat dibawa ke mereka.

Hamparan digunakan di ACI tidak hanya untuk menyediakan konektivitas fleksibel melalui jaringan transportasi, tetapi juga untuk mentransfer informasi meta (digunakan, misalnya, untuk menerapkan kebijakan keamanan).

Chip dari Broadcom sebelumnya digunakan oleh Cisco di sakelar seri Nexus 3000. Dalam keluarga Nexus 9000, yang dirilis khusus untuk mendukung ACI, model hybrid awalnya diterapkan, yang disebut Merchant +. Peralihan tersebut secara bersamaan menggunakan chip Broadcom Trident 2 baru dan chip pelengkap yang dikembangkan oleh Cisco, yang mengimplementasikan semua keajaiban ACI. Rupanya, ini memungkinkan untuk mempercepat peluncuran produk dan mengurangi label harga sakelar ke tingkat yang mendekati model hanya berdasarkan Trident 2. Pendekatan ini cukup untuk dua atau tiga tahun pertama pengiriman ACI. Selama waktu ini, Cisco mengembangkan dan meluncurkan Nexus 9000 generasi berikutnya dengan chipnya sendiri dengan lebih banyak kinerja dan rangkaian fitur, tetapi dengan tingkat harga yang sama. Spesifikasi eksternal dalam hal interaksi di pabrik benar-benar terjaga. Pada saat yang sama, pengisian internal telah berubah total: seperti refactoring, tetapi untuk perangkat keras.

Bagaimana Arsitektur Cisco ACI Bekerja

Dalam kasus paling sederhana, ACI dibangun di atas topologi jaringan Klose, atau, seperti yang sering mereka katakan, Spine-Leaf. Sakelar tingkat tulang belakang bisa dari dua (atau satu, jika kita tidak peduli dengan toleransi kesalahan) hingga enam. Dengan demikian, semakin banyak dari mereka, semakin tinggi toleransi kesalahan (semakin rendah pengurangan bandwidth dan keandalan jika terjadi kecelakaan atau pemeliharaan satu Spine) dan kinerja keseluruhan. Semua koneksi eksternal menuju ke sakelar tingkat daun: ini adalah server, dan berlabuh dengan jaringan eksternal melalui L2 atau L3, dan menghubungkan pengontrol APIC. Secara umum, dengan ACI, tidak hanya konfigurasi, tetapi juga pengumpulan statistik, pemantauan kegagalan, dan sebagainya - semuanya dilakukan melalui antarmuka pengontrol, yang tiga di antaranya dalam implementasi berukuran standar.

Anda tidak perlu terhubung ke sakelar dengan konsol, bahkan untuk memulai jaringan: pengontrol itu sendiri mendeteksi sakelar dan merakit pabrik darinya, termasuk pengaturan semua protokol layanan, oleh karena itu, sangat penting untuk tuliskan nomor seri peralatan yang dipasang saat pemasangan, agar nantinya Anda tidak perlu menebak-nebak saklar mana yang berada di rak mana. Untuk pemecahan masalah, jika perlu, Anda dapat terhubung ke sakelar melalui SSH: sakelar tersebut mereproduksi perintah pertunjukan Cisco yang biasa dengan cukup hati-hati.

Secara internal, pabrik menggunakan transportasi IP, jadi tidak ada Spanning Tree dan kengerian masa lalu lainnya di dalamnya: semua tautan terlibat, dan konvergensi jika terjadi kegagalan sangat cepat. Lalu lintas di fabric ditransmisikan melalui terowongan berdasarkan VXLAN. Lebih tepatnya, Cisco sendiri menyebut enkapsulasi iVXLAN, dan ini berbeda dari VXLAN biasa karena bidang yang dicadangkan di header jaringan digunakan untuk mengirimkan informasi layanan, terutama tentang hubungan lalu lintas ke grup EPG. Ini memungkinkan Anda menerapkan aturan interaksi antar grup dalam peralatan, menggunakan nomornya dengan cara yang sama seperti alamat yang digunakan dalam daftar akses biasa.

Terowongan memungkinkan segmen L2 dan segmen L3 (yaitu VRF) untuk diregangkan melalui transpor IP internal. Dalam hal ini, gateway default didistribusikan. Ini berarti bahwa setiap switch bertanggung jawab untuk merutekan lalu lintas yang memasuki fabric. Dalam hal logika arus lalu lintas, ACI mirip dengan struktur VXLAN/EVPN.

Jika demikian, apa perbedaannya? Yang lainnya!

Perbedaan nomor satu yang Anda temui dengan ACI adalah bagaimana server terhubung ke jaringan. Dalam jaringan tradisional, penyertaan server fisik dan mesin virtual masuk ke VLAN, dan yang lainnya menari darinya: konektivitas, keamanan, dll. Di ACI, desain digunakan yang disebut Cisco EPG (End-point Group), dari mana tidak ada tempat untuk melarikan diri. Apakah mungkin untuk menyamakannya dengan VLAN? Ya, tapi dalam hal ini ada kemungkinan kehilangan sebagian besar dari apa yang ACI berikan.

Sehubungan dengan EPG, semua aturan akses dirumuskan, dan di ACI, prinsip "daftar putih" digunakan secara default, yaitu, hanya lalu lintas yang diizinkan, yang bagiannya diizinkan secara eksplisit. Yaitu, kita dapat membuat grup EPG "Web" dan "MySQL" dan menentukan aturan yang memungkinkan komunikasi di antara mereka hanya pada port 3306. Ini akan berfungsi tanpa terikat ke alamat jaringan dan bahkan dalam subnet yang sama!

Kami memiliki pelanggan yang telah memilih ACI justru karena fitur ini, karena memungkinkan Anda untuk membatasi akses antar server (virtual atau fisik - tidak masalah) tanpa menyeretnya di antara subnet, yang berarti tanpa menyentuh pengalamatan. Ya, ya, kami tahu bahwa tidak ada yang meresepkan alamat IP secara manual dalam konfigurasi aplikasi, bukan?

Aturan lalu lintas di ACI disebut kontrak. Dalam kontrak seperti itu, satu atau lebih grup atau level dalam aplikasi multi-tier menjadi penyedia layanan (katakanlah, layanan database), yang lain menjadi konsumen. Kontrak dapat dengan mudah melewatkan lalu lintas, atau dapat melakukan sesuatu yang lebih rumit, misalnya mengarahkannya ke firewall atau penyeimbang, dan juga mengubah nilai QoS.

Bagaimana server masuk ke grup ini? Jika ini adalah server fisik atau sesuatu yang termasuk dalam jaringan yang ada tempat kami membuat batang VLAN, maka untuk menempatkannya di EPG, Anda perlu mengarahkan ke port switch dan VLAN yang digunakan di dalamnya. Seperti yang Anda lihat, VLAN muncul di tempat yang tidak dapat Anda lakukan tanpanya.

Jika server adalah mesin virtual, maka cukup merujuk ke lingkungan virtualisasi yang terhubung, dan kemudian semuanya akan terjadi dengan sendirinya: grup port akan dibuat (dalam istilah VMWare) untuk menghubungkan VM, VLAN atau VXLAN yang diperlukan akan ditugaskan, mereka akan didaftarkan pada port switch yang diperlukan, dll. Jadi, meskipun ACI dibangun di sekitar jaringan fisik, koneksi untuk server virtual terlihat jauh lebih sederhana daripada yang fisik. ACI sudah memiliki konektivitas bawaan dengan VMWare dan MS Hyper-V, serta dukungan untuk OpenStack dan RedHat Virtualization. Dari beberapa titik, dukungan bawaan untuk platform kontainer juga telah muncul: Kubernetes, OpenShift, Cloud Foundry, sementara itu menyangkut penerapan kebijakan dan pemantauan, yaitu, administrator jaringan dapat segera melihat host mana yang bekerja pada pod dan mereka termasuk dalam kelompok mana.

Selain termasuk dalam grup port tertentu, server virtual memiliki properti tambahan: nama, atribut, dll., Yang dapat digunakan sebagai kriteria untuk mentransfernya ke grup lain, misalnya, saat VM diganti namanya atau tag tambahan muncul di dia. Cisco menyebut grup segmentasi mikro ini, meskipun, pada umumnya, desainnya sendiri dengan kemampuan untuk membuat banyak segmen keamanan dalam bentuk EPG pada subnet yang sama juga merupakan segmentasi mikro. Nah, vendor lebih tahu.

EPG sendiri adalah konstruksi logis murni, tidak terikat pada sakelar, server tertentu, dll., sehingga Anda dapat melakukan berbagai hal dengannya dan konstruksi berdasarkan padanya (aplikasi dan penyewa) yang sulit dilakukan di jaringan biasa, seperti kloning. Akibatnya, katakanlah sangat mudah untuk mengkloning lingkungan produksi untuk mendapatkan lingkungan pengujian yang dijamin identik dengan lingkungan produksi. Anda dapat melakukannya secara manual, tetapi lebih baik (dan lebih mudah) melalui API.

Secara umum, logika kontrol di ACI sama sekali tidak mirip dengan yang biasa Anda temui
dalam jaringan tradisional dari Cisco yang sama: antarmuka perangkat lunak adalah yang utama, dan GUI atau CLI adalah yang kedua, karena keduanya bekerja melalui API yang sama. Oleh karena itu, hampir semua orang yang terlibat dalam ACI, setelah beberapa saat, mulai menavigasi model objek yang digunakan untuk manajemen dan mengotomatiskan sesuatu agar sesuai dengan kebutuhan mereka. Cara termudah untuk melakukannya adalah dari Python: ada alat siap pakai yang nyaman untuk itu.

Penggaruk yang dijanjikan

Masalah utamanya adalah banyak hal di ACI dilakukan secara berbeda. Untuk mulai mengerjakannya secara normal, Anda perlu berlatih ulang. Ini terutama berlaku untuk tim operasi jaringan di pelanggan besar, di mana para insinyur telah "meresepkan VLAN" selama bertahun-tahun berdasarkan permintaan. Fakta bahwa sekarang VLAN bukan lagi VLAN, dan Anda tidak perlu membuat VLAN dengan tangan untuk meletakkan jaringan baru di host virtual, benar-benar menghancurkan jaringan tradisional dan membuat mereka bergantung pada pendekatan yang sudah dikenal. Perlu dicatat bahwa Cisco mencoba sedikit mempermanis pil dan menambahkan CLI "mirip NXOS" ke pengontrol, yang memungkinkan Anda melakukan konfigurasi dari antarmuka yang mirip dengan sakelar tradisional. Tapi tetap saja, untuk mulai menggunakan ACI secara normal, Anda harus memahami cara kerjanya.

Dalam hal harga, pada skala besar dan menengah, jaringan ACI sebenarnya tidak berbeda dari jaringan tradisional pada peralatan Cisco, karena sakelar yang sama digunakan untuk membangunnya (Nexus 9000 dapat bekerja di ACI dan dalam mode tradisional dan sekarang telah menjadi yang utama "pekerja keras" untuk proyek pusat data baru). Namun untuk data center dua switch, kehadiran controller dan arsitektur Spine-Leaf tentunya membuat dirinya terasa. Baru-baru ini, pabrik Mini ACI telah muncul, di mana dua dari tiga pengontrol digantikan oleh mesin virtual. Ini mengurangi perbedaan biaya, tetapi tetap ada. Jadi untuk pelanggan, pilihannya ditentukan oleh seberapa besar ketertarikannya pada fitur keamanan, integrasi dengan virtualisasi, satu titik kontrol, dan sebagainya.

Sumber: www.habr.com

Tambah komentar