Dalam artikel ini, kami akan memeriksa mengapa pendekatan tradisional untuk menggabungkan jaringan lokal di tingkat L2 tidak efektif dengan peningkatan yang signifikan dalam jumlah peralatan, serta memberi tahu Anda masalah apa yang dapat kami pecahkan dalam proses menggabungkan proyek yang berlokasi di lokasi yang berbeda.
Sirkuit L2 normal
Ketika infrastruktur TI tumbuh di pusat data, pelanggan perlu menggabungkan server, penyimpanan, firewall menjadi satu jaringan. Untuk ini, Selectel awalnya menyarankan menggunakan jaringan area lokal.
Jaringan lokal diatur sebagai jaringan "kampus" klasik dalam pusat data yang sama, hanya sakelar akses yang ditempatkan langsung di rak dengan server. Sakelar akses selanjutnya digabungkan menjadi sakelar lapisan agregasi tunggal. Setiap klien dapat
memesan koneksi ke jaringan lokal untuk perangkat apa pun yang ia sewa atau tempatkan bersama kami di pusat data.
Untuk mengatur jaringan lokal, akses khusus dan switch agregasi digunakan, sehingga masalah dalam jaringan Internet tidak mempengaruhi jaringan lokal.
Tidak peduli rak apa yang ada di server berikutnya - Selectel menggabungkan server menjadi satu jaringan lokal, dan Anda tidak perlu memikirkan sakelar atau lokasi server. Anda dapat
memesan server saat dibutuhkan dan akan terhubung ke jaringan lokal.
L2 berfungsi dengan baik sementara ukuran pusat data kecil, ketika tidak semua rak penuh. Tetapi karena jumlah rak, server di rak, switch, klien meningkat, sirkuit menjadi lebih sulit untuk dipelihara.
Server satu klien dapat ditempatkan di beberapa
pusat data untuk memastikan toleransi bencana atau jika tidak mungkin menempatkan server di pusat data yang ada (misalnya, semua rak dan semua tempat ditempati). Di antara beberapa pusat data, konektivitas juga diperlukan - antara server di jaringan lokal.
Ketika jumlah pusat data, rak, server bertambah, sirkuit menjadi lebih rumit. Pada awalnya, konektivitas antara server dari pusat data yang berbeda dilakukan hanya pada tingkat agregasi switch menggunakan teknologi VLAN.
Tetapi ruang identifikasi VLAN sangat terbatas (4095 ID VLAN). Jadi untuk setiap pusat data, Anda harus menggunakan set VLAN Anda sendiri, yang mengurangi jumlah pengidentifikasi yang dapat digunakan di antara pusat data.
Masalah L2
Saat menggunakan skema di tingkat L2 menggunakan VLAN, operasi yang salah dari salah satu server di pusat data dapat menyebabkan gangguan dalam penyediaan layanan di server lain. Masalah yang paling umum termasuk:
- Masalah dengan STP (Spanning-Tree Protocol)
- Masalah dengan Broadcast Storms
- Masalah dengan pemrosesan multicast yang salah
- Faktor Manusia (Transfer Tautan, Transfer VLAN)
- Masalah dengan organisasi reservasi untuk L2
- Masalah dengan lalu lintas yang tidak diketahui-unicast
- Masalah dengan jumlah alamat MAC
Masalah dengan STP sering berhubungan dengan pengaturan server klien atau peralatan klien. Tidak seperti titik pertukaran lalu lintas yang populer, kami tidak dapat sepenuhnya memfilter STP pada port akses dan quench port ketika STP PDU tiba. Di STP, sejumlah produsen peralatan jaringan mengimplementasikan fungsionalitas dasar switch pusat data seperti mendeteksi loop dalam jaringan.
Jika STP tidak bekerja dengan benar di sisi klien, seluruh domain STP dari setidaknya satu saklar akses mungkin terpengaruh. Menggunakan ekstensi STP, seperti MSTP, juga bukan solusi, karena jumlah port, VLAN, sakelar seringkali melebihi skalabilitas arsitektur dari protokol STP.
Siaran
Jaringan di pusat data dapat dibangun di perangkat dari berbagai produsen. Kadang-kadang bahkan perbedaan dalam versi perangkat lunak switch sudah cukup untuk switch untuk menangani STP secara berbeda. Jadi, misalnya, di data pusat
Dubrovka 3 ada 280 rak, yang melebihi jumlah maksimum yang mungkin switch dalam satu domain STP.
Dengan meluasnya penggunaan STP dalam jaringan seperti itu, waktu respons untuk setiap perubahan, khususnya, hanya mengaktifkan atau menonaktifkan port, akan melampaui semua ambang tunggu. Anda tidak ingin itu ketika salah satu klien menyalakan port, konektivitas jaringan Anda menghilang selama beberapa menit?
Masalah dengan lalu lintas siaran sering muncul baik karena tindakan yang salah di server (misalnya, membuat satu jembatan antara beberapa port server), serta karena konfigurasi perangkat lunak yang salah di server. Kami mencoba untuk meratakan kemungkinan masalah dengan jumlah lalu lintas siaran yang masuk ke jaringan kami. Tetapi kita dapat melakukan ini pada satu port koneksi server, dan jika 5 server disertakan dalam satu switch, yang masing-masing tidak melebihi ambang batas yang ditetapkan, maka bersama-sama mereka dapat menghasilkan lalu lintas yang cukup untuk memicu kontrol pada switch agregasi. Dari praktik kami sendiri, masalah dengan badai siaran dari sisi server dapat disebabkan oleh kegagalan spesifik kartu jaringan server.
Dengan melindungi seluruh jaringan, saklar agregasi akan "menempatkan" port tempat anomali jaringan terjadi. Sayangnya, ini akan menyebabkan tidak dapatnya pengoperasian lima server yang menyebabkan insiden ini, serta ketidakmampuan server lain (hingga beberapa rak di pusat data).
Multicast
Masalah dengan pemrosesan lalu lintas multicast yang salah adalah masalah yang sangat spesifik yang muncul dalam kompleks karena kesalahan pengoperasian perangkat lunak di server dan perangkat lunak pada sakelar. Misalnya, Corosync dikonfigurasi dalam mode multicast antara beberapa server. Secara teratur pertukaran paket Hello dilakukan dalam volume kecil. Tetapi dalam beberapa kasus, server dengan Corosync diinstal dapat meneruskan paket yang cukup banyak. Volume ini sudah memerlukan konfigurasi khusus sakelar, atau penggunaan mekanisme pemrosesan yang benar (IGMP join dan lainnya). Dalam hal operasi mekanisme yang tidak benar atau ketika ambang dipicu, mungkin ada gangguan layanan yang mempengaruhi pelanggan lain. Tentu saja, semakin sedikit klien yang aktif, semakin kecil kemungkinan akan terjadi masalah dari klien lain.
Faktor manusia adalah jenis masalah yang agak tak terduga yang dapat muncul ketika bekerja dengan peralatan jaringan. Ketika administrator jaringan sendirian, dan dia kompeten membangun pekerjaannya, mendokumentasikan tindakan dan merenungkan konsekuensi dari tindakannya, maka kemungkinan kesalahannya cukup kecil. Tetapi ketika jumlah peralatan yang beroperasi di pusat data tumbuh, ketika ada banyak karyawan, ketika ada banyak tugas, maka pendekatan yang sama sekali berbeda untuk mengatur pekerjaan diperlukan.
Beberapa jenis tindakan tipikal diotomatiskan untuk menghindari kesalahan manusia, tetapi banyak jenis tindakan tidak dapat diotomatisasi saat ini, atau harga otomatisasi tindakan semacam itu sangat tinggi. Misalnya, perpindahan fisik kabel patch pada panel patch, menghubungkan tautan baru, mengganti tautan yang ada. Segala sesuatu yang berkaitan dengan kontak fisik dengan SCS. Ya, ada panel tambalan yang memungkinkan perpindahan jarak jauh, tetapi sangat mahal, membutuhkan banyak pekerjaan persiapan dan kemampuannya sangat terbatas.
Tidak ada panel patch otomatis yang akan meletakkan kabel baru jika diperlukan. Anda dapat membuat kesalahan saat mengkonfigurasi switch atau router. Tunjukkan nomor port yang salah, nomor VLAN, disegel saat memasukkan nilai numerik. Saat menentukan pengaturan tambahan, jangan memperhitungkan pengaruhnya terhadap konfigurasi yang ada. Dengan meningkatnya kompleksitas skema, memperumit skema redundansi (misalnya, karena skema saat ini mencapai batas skala), kemungkinan kesalahan manusia meningkat. Siapa pun dapat memiliki kesalahan manusia, terlepas dari apakah perangkat itu dalam tahap konfigurasi, server, switch, router, atau semacam perangkat transit.
Mengelola cadangan L2 pada pandangan pertama tampaknya seperti tugas sederhana untuk jaringan kecil. Kursus ICND Cisco mencakup dasar-dasar penggunaan STP sebagai protokol yang awalnya dirancang untuk memberikan redundansi L2. STP memiliki banyak batasan yang disebut "oleh desain" dalam protokol ini. Kita tidak boleh lupa bahwa setiap domain STP memiliki "lebar" yang sangat terbatas, yaitu, jumlah perangkat dalam satu domain STP cukup kecil dibandingkan dengan jumlah rak di pusat data. Protokol STP dalam versi aslinya membagi tautan menjadi bekas dan cadangan, yang tidak menyediakan pemanfaatan lengkap uplink selama operasi normal.
Menggunakan protokol reservasi L2 lainnya membebankan batasannya. Misalnya, ERPS (Ethernet Ring Protection Switching) - untuk topologi fisik yang digunakan, untuk jumlah dering pada satu perangkat, untuk pemanfaatan semua tautan. Penggunaan protokol lain, sebagai suatu peraturan, melibatkan perubahan kepemilikan dari produsen yang berbeda atau membatasi pembangunan jaringan untuk satu teknologi yang dipilih (misalnya, pabrik TRILL / SPBm menggunakan peralatan Avaya).
Unknown-unicast
Saya terutama ingin menyoroti subtipe masalah dengan lalu lintas yang tidak diketahui-unicast. Apa ini Lalu lintas yang diperuntukkan untuk alamat IP tertentu melalui L3, tetapi disiarkan di jaringan melalui L2, yaitu, itu dikirim ke semua port milik VLAN ini. Situasi ini dapat muncul karena sejumlah alasan, misalnya, ketika menerima DDoS ke alamat IP yang tidak dihuni. Atau jika selama salah ketik dalam konfigurasi server, alamat yang tidak ada di jaringan ditetapkan sebagai cadangan, dan pada server secara historis ada catatan ARP statis di alamat ini. Unknown-unicast muncul ketika semua entri dalam tabel ARP hadir, tetapi tidak adanya alamat MAC penerima di tabel switching switch transit.
Sebagai contoh, port di mana host jaringan dengan alamat yang diberikan sangat sering masuk ke keadaan tidak aktif. Jenis lalu lintas ini dibatasi oleh sakelar transit dan sering disajikan dengan cara yang sama seperti siaran atau multicast. Tetapi tidak seperti mereka, lalu lintas yang tidak diketahui-unicast dapat dimulai "dari Internet", dan bukan hanya dari jaringan klien. Risiko lalu lintas tidak diketahui-unicast sangat tinggi ketika menyaring aturan tentang router perbatasan memungkinkan spoofing alamat IP dari luar.
Bahkan banyaknya alamat MAC terkadang bisa menjadi masalah. Tampaknya dengan ukuran pusat data sebesar 200 rak, 40 server per rak, kecil kemungkinan bahwa jumlah alamat MAC akan jauh melebihi jumlah server di pusat data. Tapi ini bukan lagi pernyataan, karena salah satu sistem virtualisasi dapat diluncurkan di server, dan setiap mesin virtual dapat diwakili oleh alamat MAC-nya, atau bahkan beberapa (ketika meniru beberapa kartu jaringan dalam mesin virtual, misalnya). Secara total, kami bisa mendapatkan lebih dari beberapa ribu alamat MAC yang sah dari satu rak di 40 server.
Sejumlah alamat MAC dapat memengaruhi kepenuhan tabel switching pada beberapa model sakelar. Selain itu, untuk model sakelar tertentu, saat mengisi tabel switching, hashing digunakan, dan beberapa alamat MAC dapat menyebabkan benturan hash yang mengarah pada tampilan lalu lintas unicast yang tidak diketahui. Pencarian acak alamat MAC pada server yang disewa dengan kecepatan, katakanlah, 4.000 alamat per detik, dapat menyebabkan tabel switching melimpah pada saklar akses. Secara alami, switch menerapkan batasan pada jumlah alamat MAC yang dapat dipelajari pada port switch, tetapi tergantung pada implementasi spesifik dari mekanisme ini, data dapat diinterpretasikan dengan cara yang berbeda.
Sekali lagi, mengirimkan lalu lintas ke alamat MAC yang difilter oleh mekanisme ini mengarah pada tampilan lalu lintas yang tidak diketahui-unicast. Hal yang paling tidak menyenangkan dalam situasi ini adalah sakelar jarang diuji oleh pabrikan untuk penyembuhan diri sendiri setelah kasus dengan luapan meja switching. Satu luapan tabel, yang disebabkan, katakanlah, oleh kesalahan satu klien dalam parameter hping atau dalam penulisan skrip yang memantau infrastrukturnya, dapat menyebabkan reboot saklar dan gangguan komunikasi untuk semua server yang terletak di rak. Jika kelebihan seperti itu terjadi pada sakelar level agregasi, maka mem-boot ulang sakelar dapat mengakibatkan waktu henti selama 15 menit dari seluruh jaringan lokal pusat data.
Saya ingin menyampaikan bahwa penggunaan L2 hanya dibenarkan untuk kasus terbatas dan memberlakukan banyak pembatasan. Ukuran segmen, jumlah segmen L2 - ini semua adalah parameter yang harus dievaluasi setiap kali Anda menambahkan VLAN baru dengan konektivitas L2. Dan semakin kecil segmen L2, semakin sederhana dan, sebagai hasilnya, semakin andal jaringan dalam layanan.
Kasus Penggunaan L2 Khas
Seperti yang telah disebutkan, dengan pengembangan infrastruktur secara bertahap di satu pusat data, jaringan lokal L2 digunakan. Sayangnya, penggunaan ini juga tersirat dalam pengembangan proyek di pusat data lain atau dalam teknologi lain (misalnya, mesin virtual di cloud).
Tautan depan dan belakang, cadangan
Sebagai aturan, penggunaan jaringan lokal dimulai dengan pemisahan fungsionalitas dari layanan depan dan back-end, mengalokasikan DBMS ke server terpisah (untuk meningkatkan kinerja, untuk memisahkan jenis OS pada server aplikasi dan DBMS). Awalnya, penggunaan L2 untuk tujuan ini tampaknya dibenarkan, di segmen ini hanya ada beberapa server, seringkali mereka bahkan berada di rak yang sama.
Server disertakan dalam satu VLAN, dalam satu atau beberapa sakelar. Dengan meningkatnya jumlah peralatan, semakin banyak server baru yang dimasukkan dalam sakelar rak baru di pusat data, yang darinya domain L2 mulai bertambah lebar.
Server baru muncul, termasuk server basis data cadangan, server cadangan, dan sejenisnya. Selama proyek tinggal di satu pusat data, masalah penskalaan, sebagai aturan, tidak muncul. Pengembang aplikasi hanya terbiasa dengan kenyataan bahwa pada server berikutnya di jaringan lokal, alamat IP berubah hanya dalam oktet terakhir, dan Anda tidak perlu menulis aturan perutean yang terpisah.
Pengembang diminta untuk menerapkan skema serupa untuk pertumbuhan proyek, ketika server berikut sudah disewa di pusat data lain atau ketika beberapa bagian dari proyek pindah ke mesin virtual
di cloud . Dalam gambar, semuanya terlihat sangat sederhana dan indah:
Tampaknya Anda hanya perlu menghubungkan dua switch agregasi di DC1 dan DC2 dengan satu VLAN. Tapi apa yang ada di balik tindakan sederhana ini?
Reservasi Sumber Daya
Pertama, kami meningkatkan lebar domain L2, sehingga semua potensi masalah jaringan lokal DC1 dapat muncul di DC2. Siapa yang akan suka bahwa servernya berlokasi di DC2, dan insiden yang terkait dengan tidak dapat diaksesnya jaringan lokal akan terjadi karena tindakan yang salah di dalam DC1?
Kedua, Anda harus berhati-hati mencadangkan VLAN ini. Sakelar agregasi di setiap pusat data adalah titik kegagalan. Kabel antara pusat data adalah titik kegagalan lainnya. Setiap titik kegagalan harus disediakan. Dua sakelar agregasi, dua kabel dari sakelar agregasi untuk mengakses sakelar, dua kabel di antara pusat data ... Setiap kali jumlah komponen bertambah, dan sirkuit menjadi lebih rumit.
Kompleksitas skema disebabkan oleh kebutuhan untuk cadangan setiap elemen dalam sistem. Untuk cadangan lengkap perangkat dan tautan, Anda perlu menduplikasi hampir setiap elemen. Pada jaringan besar seperti itu, STP tidak mungkin lagi digunakan untuk mengatur cadangan. Mungkin saja menghadirkan semua elemen jaringan, khususnya, sakelar akses, sebagai komponen cloud MPLS, kemudian redundansi akan tercapai karena fungsionalitas protokol MPLS.
Tetapi perangkat MPLS biasanya dua kali lebih mahal daripada perangkat non-MPLS. Dan perlu dicatat bahwa MPU switch di 1U, yang memiliki tingkat skalabilitas yang baik, penerapan fungsionalitas MPLS penuh di Control-plane, dalam praktiknya, tidak ada sampai saat ini. Akibatnya, saya ingin menyingkirkan atau meminimalkan dampak masalah L2 pada jaringan yang ada, tetapi pada saat yang sama menjaga kemampuan untuk memesan sumber daya.
Transisi ke L3
Jika setiap tautan dalam jaringan direpresentasikan sebagai segmen IP terpisah, dan setiap perangkat sebagai router terpisah, maka kita tidak perlu redundansi pada level L2. Redundansi tautan dan router dipastikan dengan protokol routing dinamis dan routing redundansi dalam jaringan.
Di dalam pusat data, kita dapat menyimpan skema interaksi server yang ada satu sama lain melalui L2, dan akses ke server di pusat data lain akan melalui L3.
Dengan demikian, pusat data saling terhubung oleh konektivitas L3. Artinya, ditiru bahwa router dipasang di antara pusat data (pada kenyataannya, beberapa, untuk cadangan). Ini memungkinkan Anda untuk membagi domain L2 antara pusat data, menggunakan VLAN Anda sendiri di setiap pusat data, dan berkomunikasi di antara mereka. Untuk setiap klien, Anda dapat menggunakan rentang alamat IP yang berulang, jaringan benar-benar terisolasi satu sama lain, dan Anda tidak bisa masuk ke jaringan klien lain dari jaringan satu klien (kecuali ketika kedua klien setuju untuk koneksi semacam itu).
Kami menyarankan Anda menggunakan segmen IP dari 10.0.0.0/8 menangani untuk jaringan lokal. Untuk pusat data pertama, jaringan akan, misalnya, 10.0.1.0/24, untuk yang kedua - 10.0.2.0/24. Selectel pada router menentukan alamat IP dari subnet ini. Biasanya, alamat .250-.254 dicadangkan untuk perangkat jaringan Selectel, dan alamat .254 berfungsi sebagai gateway ke LAN lain. Rute ditetapkan ke semua perangkat di semua pusat data:
route add 10.0.0.0 mask 255.0.0.0 gw 10.0.x.254Di mana x adalah nomor pusat data. Karena rute ini, server di pusat data “melihat” satu sama lain dengan routing.
Kehadiran rute semacam itu menyederhanakan penskalaan skema dalam kasus ini, misalnya, tampilan pusat data ketiga. Kemudian, untuk server di pusat data ketiga, alamat IP dari rentang berikutnya, 10.0.3.0/24, terdaftar, di router - alamat 10.0.3.254.
Fitur khusus dari implementasi skema semacam itu adalah bahwa skema ini tidak memerlukan reservasi tambahan jika terjadi kegagalan pusat data atau saluran komunikasi eksternal. Jadi, misalnya, jika pusat data 1 gagal, koneksi antara pusat data 2 dan pusat data 3 benar-benar dipertahankan, dan ketika menerapkan skema dengan umpan L2 antara pusat data melalui salah satunya, seperti pada gambar:
Koneksi antara pusat data 2 dan pusat data 3 tergantung pada efisiensi pusat data 1. Atau, organisasi tautan tambahan dan penggunaan skema reservasi L2 yang kompleks diperlukan. Dan sementara menyimpan skema L2, seluruh jaringan masih sangat sensitif terhadap pergantian yang salah, pembentukan pergantian loop, berbagai badai lalu lintas dan masalah lainnya.
Segmen L3 dalam proyek
Selain menggunakan segmen L3 yang berbeda di pusat data yang berbeda, masuk akal untuk mengalokasikan jaringan L3 yang terpisah untuk server dalam proyek yang berbeda, sering kali dibuat menggunakan teknologi yang berbeda. Sebagai contoh, server perangkat keras di pusat data dalam satu subnet IP, server virtual di pusat data yang sama, tetapi di cloud VMware, di subnet IP lain, beberapa server terkait pementasan di subnet IP ketiga . Kemudian kesalahan acak di salah satu segmen tidak menyebabkan kegagalan total semua server yang termasuk dalam jaringan lokal.
Reservasi router
Ini semua mengesankan, tetapi ada satu titik kegagalan antara proyek - ini adalah router. Apa yang harus dilakukan dalam kasus ini? Padahal, router tidak sendirian. Dua router dialokasikan untuk setiap pusat data, dan untuk setiap pelanggan mereka membentuk Virtual IP .254 menggunakan protokol VRRP.
Menggunakan VRRP antara dua perangkat yang berdekatan dengan segmen L2 umum dibenarkan. Untuk pusat data yang didistribusikan secara geografis, router yang berbeda digunakan, dan MPLS diatur di antara mereka. Dengan demikian, setiap klien yang terhubung ke jaringan lokal dengan cara ini terhubung ke L3VPN terpisah yang dibuat untuk itu pada router MPLS ini. Dan skemanya, kira-kira mendekati kenyataan, terlihat seperti ini:
Alamat gateway untuk setiap segmen .254 dicadangkan oleh VRRP antara dua router.
Kesimpulan
Meringkas semua hal di atas - mengubah jenis jaringan lokal dari L2 ke L3 memungkinkan kami untuk mempertahankan skala, meningkatkan tingkat keandalan dan toleransi kesalahan, dan juga memungkinkan kami untuk menerapkan skema redundansi tambahan. Selain itu, ini menghindari batasan dan "perangkap" L2 yang ada.
Ketika proyek dan pusat data tumbuh, solusi standar yang ada mencapai batas skalabilitasnya. Ini berarti bahwa mereka tidak lagi cocok untuk pemecahan masalah yang efektif. Persyaratan untuk keandalan dan stabilitas sistem secara keseluruhan terus meningkat, yang pada gilirannya mempengaruhi proses perencanaan. Penting untuk mempertimbangkan fakta bahwa perkiraan pertumbuhan yang optimis harus dipertimbangkan sehingga di masa depan tidak ada sistem yang tidak dapat ditingkatkan.
Beri tahu kami - apakah Anda sudah menggunakan L3VPN? Sampai jumpa di komentar.