Hari ini saya akan memberi tahu Anda tentang bagaimana ide untuk membuat jaringan internal baru untuk perusahaan kami muncul dan diimplementasikan. Posisi manajemen adalah Anda perlu melakukan proyek penuh yang sama untuk diri Anda sendiri dan untuk klien. Jika kita melakukannya dengan baik untuk diri kita sendiri, kita dapat mengundang pelanggan dan menunjukkan seberapa baik apa yang kita tawarkan kepadanya berhasil dan berhasil. Oleh karena itu, kami mendekati pengembangan konsep jaringan baru untuk kantor Moskow dengan sangat teliti, menggunakan siklus produksi penuh: analisis kebutuhan departemen → pemilihan solusi teknis → desain → implementasi → pengujian. Jadi mari kita mulai.
Memilih Solusi Teknis: Suaka Mutant
Prosedur untuk mengerjakan sistem otomatis yang kompleks saat ini paling baik dijelaskan dalam GOST 34.601-90 “Sistem otomatis. Tahapan Penciptaan”, jadi kami bekerja sesuai dengan itu. Dan sudah pada tahap pembentukan persyaratan dan pengembangan konsep, kami menemui kesulitan pertama. Organisasi dari berbagai profil - bank, perusahaan asuransi, pengembang perangkat lunak, dll. - untuk tugas dan standar mereka, mereka memerlukan jenis jaringan tertentu, yang spesifikasinya jelas dan terstandarisasi. Namun, hal ini tidak akan berhasil bagi kami.
Kenapa?
Jet Infosystems adalah perusahaan IT besar yang terdiversifikasi. Pada saat yang sama, departemen dukungan internal kami kecil (tapi membanggakan), departemen ini memastikan fungsionalitas layanan dan sistem dasar. Perusahaan ini memiliki banyak divisi yang menjalankan fungsi berbeda: ini adalah beberapa tim outsourcing yang kuat, dan pengembang sistem bisnis internal, dan keamanan informasi, dan arsitek sistem komputasi - secara umum, siapa pun itu. Oleh karena itu, tugas, sistem, dan kebijakan keamanan mereka juga berbeda. Hal ini diharapkan menimbulkan kesulitan dalam proses analisis kebutuhan dan standarisasi.
Di sini, misalnya, adalah departemen pengembangan: karyawannya menulis dan menguji kode untuk sejumlah besar pelanggan. Seringkali ada kebutuhan untuk mengatur lingkungan pengujian dengan cepat, dan sejujurnya, tidak selalu mungkin untuk merumuskan persyaratan untuk setiap proyek, meminta sumber daya, dan membangun lingkungan pengujian terpisah sesuai dengan semua peraturan internal. Hal ini menimbulkan situasi yang aneh: suatu hari pelayan Anda yang rendah hati melihat ke ruang pengembang dan menemukan di bawah meja sebuah cluster Hadoop yang terdiri dari 20 desktop yang berfungsi dengan baik, yang entah kenapa terhubung ke jaringan umum. Saya rasa tidak ada gunanya mengklarifikasi bahwa departemen TI perusahaan tidak mengetahui keberadaannya. Keadaan ini, seperti banyak keadaan lainnya, bertanggung jawab atas fakta bahwa selama pengembangan proyek, istilah “cadangan mutan” lahir, yang menggambarkan keadaan infrastruktur perkantoran yang telah lama menderita.
Atau inilah contoh lainnya. Secara berkala, bangku ujian dibentuk dalam suatu departemen. Hal ini terjadi pada Jira dan Confluence, yang digunakan secara terbatas oleh Pusat Pengembangan Perangkat Lunak di beberapa proyek. Setelah beberapa waktu, departemen lain mempelajari sumber daya yang berguna ini, mengevaluasinya, dan pada akhir tahun 2018, Jira dan Confluence beralih dari status “mainan pemrogram lokal” ke status “sumber daya perusahaan”. Sekarang pemilik harus ditugaskan ke sistem ini, SLA, kebijakan keamanan akses/informasi, kebijakan cadangan, pemantauan, aturan untuk perutean permintaan untuk memperbaiki masalah harus ditentukan - secara umum, semua atribut sistem informasi lengkap harus ada. .
Setiap divisi kami juga merupakan inkubator yang mengembangkan produknya sendiri. Beberapa di antaranya mati pada tahap pengembangan, beberapa kami gunakan saat mengerjakan proyek, sementara yang lain mengakar dan menjadi solusi replikasi yang mulai kami gunakan sendiri dan jual kepada klien. Untuk setiap sistem seperti itu, diinginkan untuk memiliki lingkungan jaringannya sendiri, yang akan berkembang tanpa mengganggu sistem lain, dan pada titik tertentu dapat diintegrasikan ke dalam infrastruktur perusahaan.
Selain pembangunan, kita punya yang sangat besar dengan lebih dari 500 karyawan, dibentuk menjadi tim untuk setiap pelanggan. Mereka terlibat dalam pemeliharaan jaringan dan sistem lainnya, pemantauan jarak jauh, penyelesaian klaim, dan sebagainya. Artinya, infrastruktur SC sebenarnya adalah infrastruktur pelanggan yang saat ini bekerja dengan mereka. Keunikan bekerja dengan bagian jaringan ini adalah bahwa stasiun kerja mereka untuk perusahaan kami sebagian bersifat eksternal dan sebagian lagi internal. Oleh karena itu, untuk SC kami menerapkan pendekatan berikut - perusahaan menyediakan jaringan dan sumber daya lainnya kepada departemen terkait, dengan mempertimbangkan stasiun kerja departemen ini sebagai koneksi eksternal (dengan analogi dengan cabang dan pengguna jarak jauh).
Desain jalan raya: kami adalah operatornya (kejutan)
Setelah menilai seluruh kendala yang ada, kami menyadari bahwa kami mendapatkan jaringan operator telekomunikasi dalam satu kantor, dan kami mulai mengambil tindakan yang sesuai.
Kami menciptakan jaringan inti dengan bantuan konsumen internal, dan di masa depan juga eksternal, diberikan layanan yang diperlukan: L2 VPN, L3 VPN, atau perutean L3 reguler. Beberapa departemen memerlukan akses Internet yang aman, sementara departemen lain memerlukan akses bersih tanpa firewall, namun pada saat yang sama melindungi sumber daya perusahaan dan jaringan inti kami dari lalu lintas mereka.
Kami secara informal “menyelesaikan SLA” dengan masing-masing divisi. Sesuai dengan itu, segala kejadian yang timbul harus dihilangkan dalam jangka waktu tertentu yang telah disepakati sebelumnya. Persyaratan perusahaan untuk jaringannya ternyata ketat. Waktu respons maksimum terhadap suatu insiden jika terjadi kegagalan telepon dan email adalah 5 menit. Waktu untuk memulihkan fungsionalitas jaringan jika terjadi kegagalan biasa tidak lebih dari satu menit.
Karena kami memiliki jaringan tingkat operator, Anda hanya dapat menyambungkannya sesuai aturan. Unit layanan menetapkan kebijakan dan menyediakan layanan. Mereka bahkan tidak memerlukan informasi tentang koneksi server, mesin virtual, dan workstation tertentu. Namun pada saat yang sama, mekanisme perlindungan diperlukan, karena tidak ada satu koneksi pun yang dapat menonaktifkan jaringan. Jika loop dibuat secara tidak sengaja, pengguna lain tidak akan menyadarinya, sehingga diperlukan respons yang memadai dari jaringan. Setiap operator telekomunikasi terus-menerus memecahkan masalah serupa yang tampaknya rumit dalam jaringan intinya. Ini memberikan layanan kepada banyak klien dengan kebutuhan dan lalu lintas yang berbeda. Pada saat yang sama, pelanggan yang berbeda tidak boleh mengalami ketidaknyamanan dari lalu lintas orang lain.
Di rumah, kami memecahkan masalah ini dengan cara berikut: kami membangun jaringan backbone L3 dengan redundansi penuh, menggunakan protokol IS-IS. Jaringan overlay dibangun di atas inti berdasarkan teknologi /, menggunakan protokol perutean . Untuk mempercepat konvergensi protokol routing, teknologi BFD digunakan.
Struktur jaringan
Dalam pengujian, skema ini terbukti sangat baik - ketika saluran atau sakelar apa pun terputus, waktu konvergensi tidak lebih dari 0.1-0.2 detik, minimal paket hilang (seringkali tidak ada), sesi TCP tidak terputus, percakapan telepon tidak terganggu.
Lapisan Dasar - Perutean
Lapisan Hamparan - Perutean
Sakelar Huawei CE6870 dengan lisensi VXLAN digunakan sebagai sakelar distribusi. Perangkat ini memiliki rasio harga/kualitas yang optimal, memungkinkan Anda menghubungkan pelanggan dengan kecepatan 10 Gbit/dtk, dan menyambung ke backbone dengan kecepatan 40–100 Gbit/dtk, bergantung pada transceiver yang digunakan.
Sakelar Huawei CE6870
Sakelar Huawei CE8850 digunakan sebagai sakelar inti. Tujuannya adalah untuk mengirimkan lalu lintas dengan cepat dan andal. Tidak ada perangkat yang terhubung dengannya kecuali sakelar distribusi, mereka tidak tahu apa pun tentang VXLAN, jadi model dengan 32 port 40/100 Gbps dipilih, dengan lisensi dasar yang menyediakan perutean L3 dan dukungan untuk IS-IS dan MP-BGP protokol.
Yang paling bawah adalah saklar inti Huawei CE8850
Pada tahap desain, terjadi diskusi di dalam tim tentang teknologi yang dapat digunakan untuk mengimplementasikan koneksi toleransi kesalahan ke node jaringan inti. Kantor kami di Moskow terletak di tiga gedung, kami memiliki 7 ruang distribusi, yang masing-masing dilengkapi dengan dua sakelar distribusi Huawei CE6870 (hanya sakelar akses yang dipasang di beberapa ruang distribusi). Saat mengembangkan konsep jaringan, dua opsi redundansi dipertimbangkan:
- Konsolidasi sakelar distribusi ke dalam tumpukan yang toleran terhadap kesalahan di setiap ruang koneksi silang. Kelebihan: kesederhanaan dan kemudahan pengaturan. Kekurangan: ada kemungkinan kegagalan seluruh tumpukan yang lebih tinggi ketika terjadi kesalahan pada firmware perangkat jaringan (“kebocoran memori” dan sejenisnya).
- Menerapkan teknologi gateway M-LAG dan Anycast untuk menghubungkan perangkat ke sakelar distribusi.
Pada akhirnya, kami memilih opsi kedua. Konfigurasinya agak lebih sulit, tetapi dalam praktiknya telah menunjukkan kinerja dan keandalan yang tinggi.
Pertama-tama mari kita pertimbangkan untuk menghubungkan perangkat akhir ke sakelar distribusi:
Menyeberang
Sakelar akses, server, atau perangkat lain apa pun yang memerlukan koneksi toleransi kesalahan disertakan dalam dua sakelar distribusi. Teknologi M-LAG memberikan redundansi pada tingkat data link. Diasumsikan bahwa dua saklar distribusi muncul pada peralatan yang terhubung sebagai satu perangkat. Redundansi dan penyeimbangan beban dilakukan menggunakan protokol LACP.
Teknologi gateway Anycast menyediakan redundansi di tingkat jaringan. Sejumlah besar VRF dikonfigurasikan pada masing-masing sakelar distribusi (setiap VRF dimaksudkan untuk tujuannya sendiri - secara terpisah untuk pengguna "biasa", secara terpisah untuk telepon, secara terpisah untuk berbagai lingkungan pengujian dan pengembangan, dll.), dan di masing-masing VRF memiliki beberapa VLAN yang dikonfigurasi. Di jaringan kami, sakelar distribusi adalah gateway default untuk semua perangkat yang terhubung dengannya. Alamat IP yang sesuai dengan antarmuka VLAN adalah sama untuk kedua switch distribusi. Lalu lintas dialihkan melalui saklar terdekat.
Sekarang mari kita lihat menghubungkan switch distribusi ke kernel:
Toleransi kesalahan disediakan di tingkat jaringan menggunakan protokol IS-IS. Harap dicatat bahwa jalur komunikasi L3 terpisah disediakan di antara sakelar, dengan kecepatan 100G. Secara fisik jalur komunikasi ini merupakan kabel Direct Access; dapat dilihat di sebelah kanan pada foto switch Huawei CE6870.
Alternatifnya adalah dengan mengatur topologi bintang ganda yang terhubung sepenuhnya "jujur", tetapi, seperti disebutkan di atas, kami memiliki 7 ruang koneksi silang di tiga gedung. Oleh karena itu, jika kita memilih topologi “bintang ganda”, kita akan membutuhkan transceiver 40G “jarak jauh” dua kali lebih banyak. Penghematan di sini sangat signifikan.
Beberapa kata perlu disampaikan tentang bagaimana teknologi gateway VXLAN dan Anycast bekerja sama. VXLAN, tanpa menjelaskan secara rinci, adalah terowongan untuk mengangkut frame Ethernet di dalam paket UDP. Antarmuka loopback dari sakelar distribusi digunakan sebagai alamat IP tujuan terowongan VXLAN. Setiap koneksi silang memiliki dua switch dengan alamat antarmuka loopback yang sama, sehingga sebuah paket dapat tiba di salah satu switch tersebut, dan frame Ethernet dapat diekstraksi darinya.
Jika switch mengetahui alamat MAC tujuan dari frame yang diambil, frame tersebut akan dikirimkan dengan benar ke tujuannya. Untuk memastikan bahwa kedua sakelar distribusi yang dipasang di sambungan silang yang sama memiliki informasi terkini tentang semua alamat MAC yang “datang” dari sakelar akses, mekanisme M-LAG bertanggung jawab untuk menyinkronkan tabel alamat MAC (serta ARP tabel) pada kedua saklar pasangan M-LAG.
Penyeimbangan lalu lintas dicapai karena adanya beberapa rute dalam jaringan underlay ke antarmuka loopback dari sakelar distribusi.
Alih-alih sebuah kesimpulan
Seperti disebutkan di atas, selama pengujian dan pengoperasian, jaringan menunjukkan keandalan yang tinggi (waktu pemulihan untuk kegagalan umum tidak lebih dari ratusan milidetik) dan kinerja yang baik - setiap koneksi silang dihubungkan ke inti melalui dua saluran 40 Gbit/s. Sakelar akses di jaringan kami ditumpuk dan dihubungkan ke sakelar distribusi melalui LACP/M-LAG dengan dua saluran 10 Gbit/s. Sebuah tumpukan biasanya berisi 5 switch dengan masing-masing 48 port, dan hingga 10 tumpukan akses terhubung ke distribusi di setiap koneksi silang. Dengan demikian, backbone menyediakan sekitar 30 Mbit/s per pengguna bahkan pada beban teoritis maksimum, yang pada saat penulisan ini cukup untuk semua aplikasi praktis kami.
Jaringan ini memungkinkan Anda mengatur pemasangan perangkat apa pun yang terhubung dengan mulus melalui L2 dan L3, menyediakan isolasi lalu lintas yang lengkap (yang disukai layanan keamanan informasi) dan domain kesalahan (yang disukai tim operasi).
Di bagian selanjutnya kami akan memberi tahu Anda bagaimana kami bermigrasi ke jaringan baru. Pantau terus!
Maxim Klochkov
Konsultan senior dari grup audit jaringan dan proyek kompleks
Pusat Solusi Jaringan
"Sistem Info Jet"
Sumber: www.habr.com