Evaluasi koneksi di bagian tengah diagram. Kami akan kembali ke mereka di bawah
Pada titik tertentu, Anda mungkin menemukan bahwa jaringan berbasis L2 yang besar dan kompleks sedang sakit parah. Pertama-tama, masalah yang terkait dengan pemrosesan lalu lintas BUM dan pengoperasian protokol STP. Kedua, arsitekturnya umumnya sudah ketinggalan zaman. Hal ini menimbulkan masalah yang tidak menyenangkan berupa downtime dan penanganan yang tidak nyaman.
Kami memiliki dua proyek paralel, di mana pelanggan dengan bijaksana menilai semua pro dan kontra dari opsi dan memilih dua solusi overlay yang berbeda, dan kami menerapkannya.
Ada kesempatan untuk membandingkan implementasinya. Bukan eksploitasi; kita harus membicarakannya dalam dua atau tiga tahun.
Jadi, apa yang dimaksud dengan struktur jaringan dengan jaringan overlay dan SDN?
Apa yang harus dilakukan dengan permasalahan mendesak arsitektur jaringan klasik?
Setiap tahun teknologi dan ide baru bermunculan. Dalam praktiknya, kebutuhan mendesak untuk membangun kembali jaringan tidak muncul dalam waktu yang cukup lama, karena melakukan semuanya dengan tangan menggunakan metode kuno yang baik juga dimungkinkan. Jadi bagaimana jika ini adalah abad kedua puluh satu? Bagaimanapun, seorang administrator harus bekerja, dan tidak duduk di kantornya.
Kemudian booming pembangunan pusat data skala besar dimulai. Kemudian menjadi jelas bahwa batas perkembangan arsitektur klasik telah tercapai, tidak hanya dalam hal kinerja, toleransi kesalahan, dan skalabilitas. Dan salah satu opsi untuk memecahkan masalah ini adalah gagasan membangun jaringan overlay di atas tulang punggung yang dirutekan.
Selain itu, dengan meningkatnya skala jaringan, masalah pengelolaan pabrik-pabrik tersebut menjadi akut, akibatnya solusi jaringan yang ditentukan perangkat lunak mulai bermunculan dengan kemampuan untuk mengelola seluruh infrastruktur jaringan secara keseluruhan. Dan ketika jaringan dikelola dari satu titik, komponen infrastruktur TI lainnya akan lebih mudah berinteraksi dengannya, dan proses interaksi tersebut lebih mudah untuk diotomatisasi.
Hampir setiap produsen besar tidak hanya peralatan jaringan, tetapi juga virtualisasi, memiliki pilihan solusi semacam itu dalam portofolionya.
Yang tersisa hanyalah mencari tahu apa yang sesuai dengan kebutuhan apa. Misalnya, untuk perusahaan besar dengan tim pengembangan dan operasi yang baik, solusi paket dari vendor tidak selalu memenuhi semua kebutuhan, dan mereka terpaksa mengembangkan solusi SD (yang ditentukan perangkat lunak) mereka sendiri. Misalnya, penyedia cloud yang terus memperluas jangkauan layanan yang diberikan kepada klien mereka, dan solusi paket tidak mampu memenuhi kebutuhan mereka.
Untuk perusahaan skala menengah, fungsionalitas yang ditawarkan oleh vendor dalam bentuk solusi dalam kotak sudah memadai dalam 99 persen kasus.
Apa itu jaringan overlay?
Apa ide di balik jaringan overlay? Pada dasarnya, Anda menggunakan jaringan terrute klasik dan membangun jaringan lain di atasnya untuk mendapatkan lebih banyak fitur. Paling sering, kita berbicara tentang mendistribusikan beban secara efektif pada peralatan dan jalur komunikasi, meningkatkan batas skalabilitas secara signifikan, meningkatkan keandalan, dan banyak manfaat keamanan (karena segmentasi). Dan solusi SDN, selain itu, memberikan peluang administrasi fleksibel yang sangat, sangat, sangat nyaman dan menjadikan jaringan lebih transparan bagi konsumennya.
Secara umum, jika jaringan lokal ditemukan pada tahun 2010-an, tampilannya akan jauh berbeda dari apa yang kita warisi dari militer pada tahun 1970-an.
Dalam hal teknologi untuk membangun fabric menggunakan jaringan overlay, saat ini terdapat banyak implementasi vendor dan proyek RFC Internet (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve, dan lainnya). Ya, ada standarnya, tetapi penerapan standar ini oleh produsen yang berbeda mungkin berbeda, jadi ketika membuat pabrik seperti itu, masih mungkin untuk sepenuhnya mengabaikan kunci vendor hanya secara teori di atas kertas.
Dengan solusi SD, segalanya menjadi lebih membingungkan; setiap vendor memiliki visinya sendiri. Ada solusi yang sepenuhnya terbuka yang, secara teori, dapat Anda selesaikan sendiri, dan ada solusi yang sepenuhnya tertutup.
Cisco menawarkan versi SDN untuk pusat data - ACI. Tentu saja, ini adalah solusi yang 100% dikunci oleh vendor dalam hal pemilihan peralatan jaringan, namun pada saat yang sama terintegrasi penuh dengan sistem virtualisasi, containerisasi, keamanan, orkestrasi, penyeimbang beban, dll. semacam kotak hitam, tanpa kemungkinan akses penuh ke semua proses internal. Tidak semua pelanggan menyetujui opsi ini, karena Anda sepenuhnya bergantung pada kualitas kode solusi tertulis dan implementasinya, namun di sisi lain, pabrikan memiliki salah satu dukungan teknis terbaik di dunia dan memiliki tim khusus yang hanya berdedikasi. untuk solusi ini. Cisco ACI dipilih sebagai solusi untuk proyek pertama.
Untuk proyek kedua, solusi Juniper dipilih. Pabrikan juga memiliki SDN sendiri untuk pusat data, namun pelanggan memutuskan untuk tidak menerapkan SDN. Fabric EVPN VXLAN tanpa menggunakan pengontrol terpusat dipilih sebagai teknologi konstruksi jaringan.
Untuk apa?
Membuat pabrik memungkinkan Anda membangun jaringan yang mudah diskalakan, toleran terhadap kesalahan, dan andal. Arsitekturnya (leaf-spine) memperhitungkan karakteristik pusat data (jalur lalu lintas, meminimalkan penundaan dan kemacetan dalam jaringan). Solusi SD di pusat data memungkinkan Anda mengelola pabrik tersebut dengan sangat mudah, cepat, dan fleksibel serta mengintegrasikannya ke dalam ekosistem pusat data.
Kedua pelanggan perlu membangun pusat data redundan untuk memastikan toleransi kesalahan, dan sebagai tambahan, lalu lintas antar pusat data harus dienkripsi.
Pelanggan pertama telah mempertimbangkan solusi tanpa kain sebagai standar yang mungkin untuk jaringan mereka, namun dalam pengujian mereka mengalami masalah dengan kompatibilitas STP antara beberapa vendor perangkat keras. Ada waktu henti yang menyebabkan layanan terhenti. Dan bagi pelanggan, hal ini sangat penting.
Cisco sudah menjadi standar perusahaan pelanggan, mereka melihat ACI dan opsi lain dan memutuskan bahwa solusi ini layak diambil. Saya menyukai otomatisasi kontrol dari satu tombol melalui satu pengontrol. Layanan dikonfigurasi lebih cepat dan dikelola lebih cepat. Kami memutuskan untuk memastikan enkripsi lalu lintas dengan menjalankan MACSec antara switch IPN dan SPINE. Dengan demikian, kami berhasil menghindari hambatan dalam bentuk gateway kripto, menghematnya, dan menggunakan bandwidth maksimum.
Pelanggan kedua memilih solusi tanpa pengontrol dari Juniper karena pusat data mereka yang ada telah memiliki instalasi kecil yang mengimplementasikan fabric EVPN VXLAN. Tapi di sana tidak toleran terhadap kesalahan (satu saklar digunakan). Kami memutuskan untuk memperluas infrastruktur pusat data utama dan membangun pabrik di pusat data cadangan. EVPN yang ada tidak sepenuhnya digunakan: enkapsulasi VXLAN sebenarnya tidak digunakan, karena semua host terhubung ke satu switch, dan semua alamat MAC dan alamat host /32 adalah lokal, gateway untuk mereka adalah switch yang sama, tidak ada perangkat lain , di mana terowongan VXLAN perlu dibangun. Mereka memutuskan untuk memastikan enkripsi lalu lintas menggunakan teknologi IPSEC antar firewall (kinerja firewall cukup).
Mereka juga mencoba ACI, namun memutuskan bahwa karena adanya vendor lock, mereka harus membeli terlalu banyak perangkat keras, termasuk mengganti peralatan baru yang baru dibeli, dan hal tersebut tidak masuk akal secara ekonomi. Ya, Cisco fabric terintegrasi dengan segalanya, tetapi hanya perangkatnya yang dimungkinkan di dalam fabric itu sendiri.
Di sisi lain, seperti yang kami katakan sebelumnya, Anda tidak bisa begitu saja mencampurkan fabric EVPN VXLAN dengan vendor tetangga mana pun, karena implementasi protokolnya berbeda. Ini seperti melintasi Cisco dan Huawei dalam satu jaringan - sepertinya standarnya sama, tetapi Anda harus menari dengan rebana. Karena ini adalah bank, dan pengujian kompatibilitas akan memakan waktu yang sangat lama, kami memutuskan bahwa lebih baik membeli dari vendor yang sama sekarang, dan tidak terlalu terbawa oleh fungsionalitas di luar fungsi dasar.
Rencana migrasi
Dua pusat data berbasis ACI:
Organisasi interaksi antar pusat data. Solusi Multi-Pod dipilih - setiap pusat data adalah sebuah pod. Persyaratan untuk penskalaan berdasarkan jumlah sakelar dan penundaan antar pod (RTT kurang dari 50 ms) juga diperhitungkan. Diputuskan untuk tidak membangun solusi Multi-Situs demi kemudahan pengelolaan (solusi Multi-Pod menggunakan antarmuka manajemen tunggal, Multi-Situs akan memiliki dua antarmuka, atau akan memerlukan Orchestrator Multi-Situs), dan karena tidak ada geografis reservasi situs diperlukan.
Dari sudut pandang migrasi layanan dari jaringan Legacy, opsi paling transparan dipilih, secara bertahap mentransfer VLAN yang sesuai dengan layanan tertentu.
Untuk migrasi, EPG (Grup Titik Akhir) yang sesuai dibuat untuk setiap VLAN di pabrik. Pertama, jaringan direntangkan antara jaringan lama dan fabric melalui L2, kemudian setelah semua host dimigrasi, gateway dipindahkan ke fabric, dan EPG berinteraksi dengan jaringan yang ada melalui L3OUT, sedangkan interaksi antara L3OUT dan EPG dijelaskan menggunakan kontrak. Diagram perkiraan:
Contoh struktur sebagian besar kebijakan pabrik ACI ditunjukkan pada gambar di bawah. Keseluruhan penyiapan didasarkan pada kebijakan yang dirangkai dalam kebijakan lain dan seterusnya. Pada awalnya sangat sulit untuk mengetahuinya, tetapi secara bertahap, seperti yang ditunjukkan oleh praktik, administrator jaringan akan terbiasa dengan struktur ini dalam waktu sekitar satu bulan, dan kemudian mereka baru mulai memahami betapa nyamannya struktur ini.
Π‘ΡΠ°Π²Π½Π΅Π½ΠΈΠ΅
Dalam solusi Cisco ACI, Anda perlu membeli lebih banyak peralatan (saklar terpisah untuk interaksi Inter-Pod dan pengontrol APIC), yang membuatnya lebih mahal. Solusi Juniper tidak memerlukan pembelian pengontrol atau aksesori; Peralatan yang ada milik pelanggan dapat digunakan sebagian.
Berikut adalah arsitektur fabric EVPN VXLAN untuk dua pusat data proyek kedua:
Dengan ACI Anda mendapatkan solusi siap pakai - tidak perlu mengutak-atik, tidak perlu mengoptimalkan. Selama pengenalan awal pelanggan dengan pabrik, tidak diperlukan pengembang, tidak diperlukan orang pendukung untuk kode dan otomatisasi. Penggunaannya cukup mudah; banyak pengaturan dapat dilakukan melalui wizard, yang tidak selalu merupakan nilai tambah, terutama bagi orang yang terbiasa dengan baris perintah. Bagaimanapun, dibutuhkan waktu untuk membangun kembali otak ke jalur baru, ke kekhasan pengaturan melalui kebijakan dan beroperasi dengan banyak kebijakan yang tersarang. Selain itu, sangat diharapkan adanya struktur yang jelas dalam penamaan kebijakan dan objek. Jika ada masalah yang muncul pada logika pengontrol, itu hanya dapat diselesaikan melalui dukungan teknis.
Di EVPN - konsol. Menderita atau bersukacita. Antarmuka yang familier bagi penjaga lama. Ya, ada konfigurasi dan panduan standar. Anda harus menghisap mana. Beda desain, semuanya jelas dan detail.
Biasanya, dalam kedua kasus tersebut, saat melakukan migrasi, lebih baik melakukan migrasi terlebih dahulu bukan layanan yang paling penting, misalnya, lingkungan pengujian, dan baru kemudian, setelah mengetahui semua bug, lanjutkan ke produksi. Dan jangan mendengarkan pada Jumat malam. Anda tidak boleh mempercayai vendor bahwa semuanya akan baik-baik saja, lebih baik selalu bermain aman.
Anda membayar lebih untuk ACI, meskipun Cisco saat ini secara aktif mempromosikan solusi ini dan sering kali memberikan diskon yang bagus, tetapi Anda menghemat pemeliharaan. Manajemen dan otomatisasi pabrik EVPN tanpa pengontrol memerlukan investasi dan biaya rutin - pemantauan, otomatisasi, implementasi layanan baru. Pada saat yang sama, peluncuran awal di ACI memakan waktu 30β40 persen lebih lama. Hal ini terjadi karena diperlukan waktu lebih lama untuk membuat seluruh rangkaian profil dan kebijakan yang diperlukan yang kemudian akan digunakan. Namun seiring pertumbuhan jaringan, jumlah konfigurasi yang diperlukan berkurang. Anda menggunakan kebijakan, profil, objek yang telah dibuat sebelumnya. Anda dapat secara fleksibel mengonfigurasi segmentasi dan keamanan, mengelola kontrak secara terpusat yang bertanggung jawab untuk memungkinkan interaksi tertentu antar EPG - jumlah pekerjaan turun tajam.
Di EVPN, Anda perlu mengkonfigurasi setiap perangkat di pabrik, kemungkinan kesalahan lebih besar.
Meskipun implementasi ACI lebih lambat, EVPN memerlukan waktu debug hampir dua kali lebih lama. Jika dalam kasus Cisco Anda selalu dapat menghubungi teknisi dukungan dan bertanya tentang jaringan secara keseluruhan (karena tercakup dalam solusi), maka dari Juniper Networks Anda hanya membeli perangkat keras, dan itulah yang tercakup. Apakah paketnya sudah meninggalkan perangkat? Baiklah, kalau begitu masalahmu. Tetapi Anda dapat membuka pertanyaan mengenai pilihan solusi atau desain jaringan - dan kemudian mereka akan menyarankan Anda untuk membeli layanan profesional, dengan biaya tambahan.
Dukungan ACI sangat keren karena terpisah: tim terpisah duduk hanya untuk ini. Ada juga spesialis berbahasa Rusia. Panduannya detail, solusinya sudah ditentukan sebelumnya. Mereka melihat dan memberi nasihat. Mereka dengan cepat memvalidasi desain, yang seringkali penting. Juniper Networks melakukan hal yang sama, tetapi jauh lebih lambat (kami punya ini, sekarang menurut rumor seharusnya lebih baik), yang memaksa Anda untuk melakukan semuanya sendiri sesuai saran teknisi solusi.
Cisco ACI mendukung integrasi dengan sistem virtualisasi dan containerisasi (VMware, Kubernetes, Hyper-V) dan manajemen terpusat. Tersedia dengan layanan jaringan dan keamanan - penyeimbangan, firewall, WAF, IPS, dll... Segmentasi mikro yang bagus. Pada solusi kedua, integrasi dengan layanan jaringan sangatlah mudah, dan lebih baik mendiskusikan forum terlebih dahulu dengan mereka yang telah melakukan hal ini.
Total
Untuk setiap kasus tertentu, perlu untuk memilih solusi, tidak hanya berdasarkan biaya peralatan, tetapi juga perlu memperhitungkan biaya operasional lebih lanjut dan masalah utama yang dihadapi pelanggan saat ini, dan rencana apa yang ada di sana. adalah untuk pengembangan infrastruktur TI.
ACI karena peralatan tambahan lebih mahal, tetapi solusinya sudah jadi tanpa perlu finishing tambahan; solusi kedua lebih kompleks dan mahal dalam hal pengoperasian, tetapi lebih murah.
Jika Anda ingin mendiskusikan berapa biaya untuk mengimplementasikan struktur jaringan pada vendor yang berbeda, dan jenis arsitektur apa yang diperlukan, Anda dapat bertemu dan mengobrol. Kami akan memberi saran secara gratis sampai Anda mendapatkan sketsa kasar arsitekturnya (yang dapat digunakan untuk menghitung anggaran), penjabaran detailnya tentu saja sudah berbayar.
Vladimir Klepche, jaringan perusahaan.
Sumber: www.habr.com