Dalam dua artikel pertama, saya mengangkat masalah otomatisasi dan membuat sketsa kerangka kerjanya, di artikel kedua saya beralih ke virtualisasi jaringan, sebagai pendekatan pertama untuk mengotomatisasi konfigurasi layanan.
Sekarang saatnya menggambar diagram jaringan fisik.
Jika Anda belum terbiasa dengan pengaturan jaringan pusat data, saya sangat menyarankan untuk memulainya .
Semua masalah:
Praktik yang dijelaskan dalam seri ini harus berlaku untuk semua jenis jaringan, ukuran apa pun, dengan variasi vendor apa pun (tidak). Namun, mustahil untuk menggambarkan contoh universal penerapan pendekatan-pendekatan ini. Oleh karena itu, saya akan fokus pada arsitektur modern jaringan DC: .
Kami akan melakukan DCI pada MPLS L3VPN.
Jaringan Overlay berjalan di atas jaringan fisik dari host (ini bisa berupa VXLAN OpenStack atau Tungsten Fabric atau apa pun yang hanya memerlukan konektivitas IP dasar dari jaringan).
Dalam hal ini, kami mendapatkan skenario otomatisasi yang relatif sederhana, karena kami memiliki banyak peralatan yang dikonfigurasi dengan cara yang sama.
Kami akan memilih DC bola dalam ruang hampa:
- Satu versi desain di mana saja.
- Dua vendor membentuk dua bidang jaringan.
- Satu DC seperti DC lainnya seperti dua kacang polong.
kadar
- Topologi fisik
- Rute
- rencana kekayaan intelektual
- Laba
- Kesimpulan
- Berguna Link
Izinkan Penyedia Layanan kami LAN_DC, misalnya, menghosting video pelatihan tentang bertahan hidup di elevator yang macet.
Di kota-kota besar, hal ini sangat populer, sehingga Anda memerlukan banyak mesin fisik.
Pertama, saya akan mendeskripsikan jaringan kira-kira seperti yang saya inginkan. Lalu saya akan menyederhanakannya untuk lab.
Topologi fisik
ΠΎΠΊΠ°ΡΠΈΠΈ
LAN_DC akan memiliki 6 DC:
- Rusia (RU):
- Moskow (msk)
- Kazan (kzn)
- Spanyol (SP):
- Barcelona (bcn)
- Malaga (mlg)
- China (CN):
- Shanghai (sha)
- Xian (kedua)
Di dalam DC (Intra-DC)
Semua DC memiliki jaringan konektivitas internal yang identik berdasarkan topologi Clos.
Apa jenis jaringan Clos itu dan mengapa mereka terpisah .
Setiap DC memiliki 10 rak dengan mesin, mereka akan diberi nomor sebagai A, B, C Dan seterusnya.
Setiap rak memiliki 30 mesin. Mereka tidak akan menarik minat kita.
Juga di setiap rak ada sakelar yang menghubungkan semua mesin - ini dia Sakelar Rak Atas - ToR atau sebaliknya, dalam istilah pabrik Clos, kami akan menyebutnya Leaf.
Diagram umum pabrik.
Kami akan menelepon mereka XXX-daunYDimana XXX - singkatan tiga huruf DC, dan Y - nomor seri. Misalnya, kzn-daun11.
Dalam artikel saya, saya akan membiarkan diri saya menggunakan istilah Leaf dan ToR secara sembrono sebagai sinonim. Namun, kita harus ingat bahwa hal ini tidak terjadi.
ToR adalah saklar yang dipasang di rak tempat mesin terhubung.
Leaf adalah peran perangkat dalam jaringan fisik atau saklar tingkat pertama dalam hal topologi Cloes.
Artinya, Daun != ToR.
Jadi Leaf bisa menjadi saklar EndofRaw, misalnya.
Namun, dalam kerangka artikel ini kami akan tetap memperlakukannya sebagai sinonim.
Setiap sakelar ToR dihubungkan ke empat sakelar agregasi tingkat yang lebih tinggi - Tulang belakang. Satu rak di DC dialokasikan untuk Spines. Kami akan menamainya dengan cara yang sama: XXX-tulang belakangY.
Rak yang sama akan berisi peralatan jaringan untuk konektivitas antara router DC - 2 dengan MPLS terpasang. Namun secara umum, ini adalah ToR yang sama. Artinya, dari sudut pandang sakelar Spine, ToR biasa dengan mesin yang terhubung atau router untuk DCI tidak menjadi masalah sama sekali - hanya meneruskan.
ToR khusus seperti itu disebut Daun tepi. Kami akan menelepon mereka XXX-tepiY.
Ini akan terlihat seperti ini.
Pada diagram di atas, saya sebenarnya menempatkan tepi dan daun pada level yang sama. Mereka mengajari kami untuk mempertimbangkan uplinking (karena itulah istilahnya) sebagai uplink. Dan di sini ternyata βuplinkβ DCI kembali turun, yang bagi sebagian orang sedikit mematahkan logika biasanya. Dalam kasus jaringan besar, ketika pusat data dibagi menjadi unit-unit yang lebih kecil - POD's (Point Of Delivery), sorot individu Tepi-PODuntuk DCI dan akses ke jaringan eksternal.
Untuk memudahkan persepsi di masa depan, saya akan tetap menggambar Edge over Spine, sementara kita ingat bahwa tidak ada kecerdasan pada Spine dan tidak ada perbedaan saat bekerja dengan Leaf dan Edge-leaf biasa (walaupun mungkin ada nuansa di sini , tapi secara umum Ini benar).
Skema pabrik dengan daun tepi.
Tritunggal Leaf, Spine dan Edge membentuk jaringan atau pabrik Underlay.
Tugas pabrik jaringan (baca Underlay), seperti yang telah kami definisikan di , sangat, sangat sederhana - untuk menyediakan konektivitas IP antar mesin baik dalam DC yang sama maupun di antara keduanya.
Itulah sebabnya jaringan disebut pabrik, seperti misalnya pabrik switching di dalam kotak jaringan modular, yang dapat Anda baca lebih lanjut di .
Secara umum topologi seperti ini disebut factory, karena fabric dalam terjemahannya berarti fabric. Dan sulit untuk tidak setuju:
Pabrik sepenuhnya L3. Tanpa VLAN, tanpa Siaran - kami memiliki pemrogram hebat di LAN_DC, mereka tahu cara menulis aplikasi yang hidup dalam paradigma L3, dan mesin virtual tidak memerlukan Migrasi Langsung dengan mempertahankan alamat IP.
Dan sekali lagi: jawaban atas pertanyaan mengapa pabrik dan mengapa L3 berada di tempat terpisah .
DCI - Interkoneksi Pusat Data (Inter-DC)
DCI akan diatur menggunakan Edge-Leaf, yaitu titik keluar kita menuju jalan raya.
Untuk mempermudah, kita asumsikan bahwa DC dihubungkan satu sama lain melalui hubungan langsung.
Mari kita kecualikan konektivitas eksternal dari pertimbangan.
Saya sadar bahwa setiap kali saya menghapus komponen, saya menyederhanakan jaringan secara signifikan. Dan ketika kita mengotomatiskan jaringan abstrak kita, semuanya akan baik-baik saja, tetapi pada jaringan nyata akan ada penopang.
Ini benar. Namun, inti dari seri ini adalah memikirkan dan mengerjakan pendekatan, bukan memecahkan masalah khayalan secara heroik.
Pada Edge-Leafs, lapisan bawah ditempatkan di VPN dan ditransmisikan melalui tulang punggung MPLS (tautan langsung yang sama).
Ini adalah diagram tingkat atas yang kami dapatkan.
Rute
Untuk routing dalam DC kita akan menggunakan BGP.
Pada batang MPLS OSPF+LDP.
Untuk DCI yaitu mengatur konektivitas di bawah tanah - BGP L3VPN melalui MPLS.
Skema perutean umum
Tidak ada OSPF atau ISIS (protokol routing yang dilarang di Federasi Rusia) di pabrik.
Ini berarti bahwa tidak akan ada Penemuan Otomatis atau perhitungan jalur terpendek - hanya manual (sebenarnya otomatis - di sini kita berbicara tentang otomatisasi) yang mengatur protokol, lingkungan, dan kebijakan.
Skema perutean BGP dalam DC
Mengapa BGP?
Pada topik ini ada dinamai Facebook dan Arista, yang menceritakan cara membangun sangat besar jaringan pusat data menggunakan BGP. Bunyinya hampir seperti fiksi, saya sangat merekomendasikannya untuk malam yang lesu.
Dan ada juga seluruh bagian dalam artikel saya yang didedikasikan untuk ini. Kemana aku harus membawamu dan .
Namun singkatnya, tidak ada IGP yang cocok untuk jaringan pusat data besar, yang jumlah perangkat jaringannya mencapai ribuan.
Selain itu, menggunakan BGP di mana pun akan memungkinkan Anda tidak membuang waktu untuk mendukung beberapa protokol berbeda dan sinkronisasi di antara keduanya.
Sejujurnya, di pabrik kami, yang kemungkinan besar tidak akan berkembang pesat, OSPF akan cukup untuk dilihat. Ini sebenarnya adalah masalah para megascaler dan cloud titans. Tapi mari kita bayangkan hanya untuk beberapa rilis saja kita membutuhkannya, dan kita akan menggunakan BGP, seperti yang diwariskan oleh Pyotr Lapukhov.
Kebijakan Perutean
Pada switch Leaf, kami mengimpor prefiks dari antarmuka jaringan Underlay ke BGP.
Kami akan mengadakan sesi BGP antara masing-masing pasangan Daun-Tulang Belakang, di mana awalan Underlay ini akan diumumkan melalui jaringan bolak-balik.
Dalam satu data center kami akan mendistribusikan spesifikasi yang kami impor ke ToRe. Di Edge-Leafs kami akan mengumpulkannya dan mengumumkannya ke DC jarak jauh dan mengirimkannya ke TOR. Artinya, setiap ToR akan mengetahui secara pasti bagaimana menuju ke ToR lain di DC yang sama dan di mana titik masuknya untuk mencapai ToR di DC lain.
Di DCI, rute akan dikirimkan sebagai VPNv4. Untuk melakukan ini, di Edge-Leaf, antarmuka menuju pabrik akan ditempatkan di VRF, sebut saja UNDERLAY, dan lingkungan dengan Spine di Edge-Leaf akan muncul di dalam VRF, dan di antara Edge-Leafs di VPNv4- keluarga.
Kami juga akan melarang pengumuman ulang rute yang diterima dari belakang mereka.
Di Leaf dan Spine kami tidak akan mengimpor Loopbacks. Kami hanya membutuhkannya untuk menentukan ID Router.
Namun di Edge-Leafs kami mengimpornya ke Global BGP. Di antara alamat Loopback, Edge-Leafs akan membuat sesi BGP dalam keluarga VPN IPv4 satu sama lain.
Kami akan memiliki tulang punggung OSPF+LDP antar perangkat EDGE. Semuanya ada dalam satu zona. Konfigurasi yang sangat sederhana.
Ini adalah gambar dengan routing.
BGP ASN
ASN Daun Tepi
Edge-Leafs akan memiliki satu ASN di semua DC. Penting bahwa ada iBGP di antara Edge-Leafs, dan kita tidak terjebak dalam nuansa eBGP. Biarlah 65535. Kenyataannya, ini bisa menjadi jumlah AS publik.
Tulang Belakang ASN
Di Spine kita akan memiliki satu ASN per DC. Mari kita mulai di sini dengan angka pertama dari rentang AS hasil bagi - 64512, 64513, dan seterusnya.
Mengapa ASN di DC?
Mari kita bagi pertanyaan ini menjadi dua:
- Mengapa ASN sama di semua duri dalam satu DC?
- Mengapa mereka berbeda di DC yang berbeda?
Mengapa ASN yang sama ada di semua duri dalam satu DC?
Seperti inilah tampilan AS-Path dari rute Underlay di Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Saat Anda mencoba mengiklankannya kembali ke Spine, ia akan membuangnya karena AS (Spine_AS)-nya sudah ada dalam daftar.
Namun, di DC kami sepenuhnya puas bahwa rute Underlay yang naik ke Edge tidak akan bisa turun. Semua komunikasi antara host dalam DC harus terjadi pada level tulang belakang.
Pada saat yang sama, rute gabungan DC lain akan dengan mudah mencapai ToR - AS-Path mereka hanya akan memiliki ASN 65535 - jumlah AS Edge-Leaf, karena di sanalah mereka dibuat.
Mengapa mereka berbeda di DC yang berbeda?
Secara teoritis, kita mungkin perlu menyeret Loopback dan beberapa mesin virtual layanan antar DC.
Misalnya pada host kita akan menjalankan Route Reflector atau (Virtual Network Gateway), yang akan mengunci dengan TopR melalui BGP dan mengumumkan loopbacknya, yang seharusnya dapat diakses dari semua DC.
Jadi seperti inilah tampilan AS-Path-nya:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Dan tidak boleh ada ASN duplikat di mana pun.
Artinya, Spine_DC1 dan Spine_DC2 harus berbeda, sama seperti leafX_DC1 dan leafY_DC2, itulah yang sedang kita dekati.
Seperti yang mungkin Anda ketahui, ada peretasan yang memungkinkan Anda menerima rute dengan ASN duplikat meskipun ada mekanisme pencegahan loop (allowas-in di Cisco). Dan bahkan memiliki kegunaan yang sah. Namun hal ini berpotensi menimbulkan kesenjangan dalam stabilitas jaringan. Dan saya pribadi mengalaminya beberapa kali.
Dan jika kita mempunyai kesempatan untuk tidak menggunakan hal-hal yang berbahaya, kita akan memanfaatkannya.
Daun ASN
Kami akan memiliki ASN individual di setiap switch Leaf di seluruh jaringan.
Kami melakukan ini karena alasan yang diberikan di atas: AS-Path tanpa loop, konfigurasi BGP tanpa bookmark.
Agar rute antar Leafs dapat dilalui dengan lancar, AS-Path akan terlihat seperti ini:
[leafX_ASN, spine_ASN, leafY_ASN]
di mana leafX_ASN dan leafY_ASN akan menyenangkan jika berbeda.
Hal ini juga diperlukan untuk situasi dengan pengumuman loopback VNF antar DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Kami akan menggunakan ASN 4-byte dan menghasilkannya berdasarkan ASN Spine dan nomor switch Leaf, yaitu seperti ini: Tulang Belakang_ASN.0000X.
Ini fotonya bersama ASN.
rencana kekayaan intelektual
Pada dasarnya, kita perlu mengalokasikan alamat untuk koneksi berikut:
- Mendasari alamat jaringan antara ToR dan mesin. Mereka harus unik dalam keseluruhan jaringan sehingga mesin mana pun dapat berkomunikasi dengan mesin lain. Sangat cocok 10/8. Untuk setiap rak ada /26 dengan cadangan. Kami akan mengalokasikan /19 per DC dan /17 per wilayah.
- Tautkan alamat antara Leaf/Tor dan Spine.
Saya ingin menetapkannya secara algoritmik, yaitu menghitungnya berdasarkan nama perangkat yang perlu dihubungkan.
Biarlah... 169.254.0.0/16.
Yaitu 169.254.00X.Y/31Dimana X - Nomor tulang belakang, Y β Jaringan P2P /31.
Ini akan memungkinkan Anda meluncurkan hingga 128 rak, dan hingga 10 Duri di DC. Alamat tautan dapat (dan akan) diulang dari DC ke DC. - Kami mengatur persimpangan Spine-Edge-Leaf pada subnet 169.254.10X.Y/31, dimana persis sama X - Nomor tulang belakang, Y β Jaringan P2P /31.
- Tautkan alamat dari Edge-Leaf ke backbone MPLS. Di sini situasinya agak berbeda - tempat di mana semua bagian terhubung menjadi satu kue, jadi menggunakan kembali alamat yang sama tidak akan berfungsi - Anda harus memilih subnet gratis berikutnya. Oleh karena itu, mari kita ambil sebagai dasar 192.168.0.0/16 dan kami akan mengambil yang gratis darinya.
- Alamat Loopback. Kami akan memberikan seluruh rangkaiannya untuk mereka 172.16.0.0/12.
- Daun - /25 per DC - 128 rak yang sama. Kami akan mengalokasikan /23 per wilayah.
- Tulang Belakang - /28 per DC - hingga 16 Tulang Belakang. Mari kita alokasikan /26 per wilayah.
- Edge-Leaf - /29 per DC - hingga 8 kotak. Mari kita alokasikan /27 per wilayah.
Jika kita tidak memiliki rentang alokasi yang cukup di DC (dan tidak akan ada rentang tersebut - kita mengaku sebagai hyperscaler), kita cukup memilih blok berikutnya.
Ini adalah gambar dengan pengalamatan IP.
Loopback:
Awalan
Peran perangkat
Wilayah
DC
172.16.0.0/23
tepi
172.16.0.0/27
ru
172.16.0.0/29
msk
172.16.0.8/29
kzn
172.16.0.32/27
sp
172.16.0.32/29
bcn
172.16.0.40/29
mlg
172.16.0.64/27
cn
172.16.0.64/29
sha
172.16.0.72/29
kedua
172.16.2.0/23
tulang belakang
172.16.2.0/26
ru
172.16.2.0/28
msk
172.16.2.16/28
kzn
172.16.2.64/26
sp
172.16.2.64/28
bcn
172.16.2.80/28
mlg
172.16.2.128/26
cn
172.16.2.128/28
sha
172.16.2.144/28
kedua
172.16.8.0/21
daun
172.16.8.0/23
ru
172.16.8.0/25
msk
172.16.8.128/25
kzn
172.16.10.0/23
sp
172.16.10.0/25
bcn
172.16.10.128/25
mlg
172.16.12.0/23
cn
172.16.12.0/25
sha
172.16.12.128/25
kedua
Mendasari:
Awalan
Wilayah
DC
10.0.0.0/17
ru
10.0.0.0/19
msk
10.0.32.0/19
kzn
10.0.128.0/17
sp
10.0.128.0/19
bcn
10.0.160.0/19
mlg
10.1.0.0/17
cn
10.1.0.0/19
sha
10.1.32.0/19
kedua
Laba
Dua vendor. Satu jaringan. ADSM.
Juniper + Arista. Ubuntu. Hawa tua yang baik.
Jumlah resource pada server virtual kami di Mirana masih terbatas, jadi untuk latihan kami akan menggunakan jaringan yang disederhanakan hingga batasnya.
Dua pusat data: Kazan dan Barcelona.
- Masing-masing dua duri: Juniper dan Arista.
- Masing-masing satu torus (Daun) - Juniper dan Arista, dengan satu host yang terhubung (mari kita gunakan Cisco IOL yang ringan untuk ini).
- Masing-masing satu node Edge-Leaf (untuk saat ini hanya Juniper).
- Satu saklar Cisco untuk mengatur semuanya.
- Selain kotak jaringan, mesin kontrol virtual sedang berjalan. Menjalankan Ubuntu.
Ia memiliki akses ke semua perangkat, ia akan menjalankan sistem IPAM/DCIM, sekumpulan skrip Python, Ansible, dan apa pun yang mungkin kami perlukan.
dari semua perangkat jaringan, yang akan kami coba reproduksi menggunakan otomatisasi.
Kesimpulan
Apakah itu juga diterima? Haruskah saya menulis kesimpulan singkat di bawah setiap artikel?
Jadi kami memilih Menutup jaringan di dalam DC, karena kami mengharapkan banyak lalu lintas Timur-Barat dan menginginkan ECMP.
Jaringan dibagi menjadi fisik (underlay) dan virtual (overlay). Pada saat yang sama, overlay dimulai dari host - sehingga menyederhanakan persyaratan untuk underlay.
Kami memilih BGP sebagai protokol perutean untuk jaringan jaringan karena skalabilitas dan fleksibilitas kebijakannya.
Kami akan memiliki node terpisah untuk mengatur DCI - Edge-leaf.
Tulang punggung akan memiliki OSPF+LDP.
DCI akan diimplementasikan berdasarkan MPLS L3VPN.
Untuk tautan P2P, kami akan menghitung alamat IP secara algoritmik berdasarkan nama perangkat.
Kami akan menetapkan loopback sesuai dengan peran perangkat dan lokasinya secara berurutan.
Awalan yang mendasari - hanya pada sakelar Leaf secara berurutan berdasarkan lokasinya.
Anggap saja saat ini kita belum memasang peralatannya.
Oleh karena itu, langkah kami selanjutnya adalah menambahkannya ke sistem (IPAM, inventaris), mengatur akses, membuat konfigurasi, dan menerapkannya.
Pada artikel berikutnya kita akan membahas Netbox - sistem inventaris dan manajemen untuk ruang IP di DC.
Terima kasih
- Andrey Glazkov alias @glazgoo untuk koreksi dan koreksi
- Alexander Klimenko alias @v00lk untuk mengoreksi dan mengedit
- Artyom Chernobay untuk KDPV
Sumber: www.habr.com