Lima tahun adalah waktu karakteristik untuk merangkum hasil antara. Oleh karena itu, kami memutuskan untuk berbicara tentang pembangunan infrastruktur kami, yang telah melalui jalur pengembangan yang sangat menarik selama lima tahun, yang kami banggakan. Perubahan kuantitatif yang kami terapkan berubah menjadi perubahan kualitatif, kini infrastruktur dapat beroperasi dalam moda yang tampak fantastis di pertengahan dekade terakhir.
Kami menyediakan pekerjaan untuk proyek paling kompleks dengan persyaratan ketat untuk keandalan dan beban, termasuk PREMIER dan Match TV. Pada siaran olahraga dan pemutaran perdana serial TV populer, lalu lintas dalam terabit harus dikembalikan, kami dengan mudah menerapkannya, dan sering kali bekerja dengan kecepatan seperti itu telah lama menjadi hal biasa bagi kami. Dan lima tahun lalu, proyek tersulit yang bekerja pada sistem kami adalah Rutube, yang telah berkembang sejak saat itu, meningkatkan volume dan lalu lintas, yang harus diperhitungkan saat merencanakan pemuatan.
Kami berbicara tentang bagaimana kami mengembangkan perangkat keras infrastruktur kami ( "Rutube 2009-2015: sejarah perangkat keras kami" ) dan mengembangkan sistem yang bertanggung jawab untuk pengunggahan video ( "Dari nol hingga 700 gigabit per detik - bagaimana salah satu situs hosting video terbesar di Rusia "), tetapi banyak waktu telah berlalu sejak penulisan teks ini, banyak solusi lain telah dibuat dan diterapkan, yang hasilnya memungkinkan kami memenuhi persyaratan modern dan cukup fleksibel untuk membangun kembali untuk tugas-tugas baru.
Kami terus mengembangkan inti jaringan . Kami beralih ke peralatan Cisco pada tahun 2015, seperti yang disebutkan di artikel terakhir. Kemudian semuanya sama 10 / 40G, tetapi untuk alasan yang jelas, setelah beberapa tahun mereka meningkatkan sasis yang ada, dan sekarang kami secara aktif menggunakan 25 / 100G juga.
Tautan 100G sudah lama bukan merupakan barang mewah (sebaliknya, ini adalah persyaratan mendesak pada saat itu di segmen kami), atau jarang (semakin banyak operator menyediakan koneksi dengan kecepatan seperti itu). Namun, 10 / 40G tetap relevan: melalui tautan ini, kami terus menghubungkan operator dengan volume lalu lintas yang kecil, yang saat ini tidak praktis untuk menggunakan port yang lebih besar.
Inti jaringan yang telah kami buat layak mendapat pertimbangan terpisah dan akan menjadi topik artikel terpisah nanti. Di sana kami akan mempelajari detail teknis dan mempertimbangkan logika tindakan kami saat membuatnya. Tapi sekarang kami akan terus menggambar infrastruktur secara lebih skematis, karena perhatian Anda, para pembaca yang budiman, tidak terbatas.
Server penyajian videoberkembang dengan cepat, yang karenanya kami menawarkan banyak upaya. Jika sebelumnya kami hanya menggunakan server 2U dengan 4-5 kartu jaringan dengan masing-masing dua port 10G, sekarang sebagian besar lalu lintas dikirim dari server 1U, di mana ada 2-3 kartu dengan masing-masing dua port 25G. Kartu dengan 10G dan 25G hampir sama harganya, dan solusi yang lebih cepat memungkinkan Anda memberikan 10G dan 25G. Hasilnya adalah penghematan yang jelas: lebih sedikit komponen server dan kabel untuk disambungkan - biaya lebih sedikit (dan lebih andal), komponen menggunakan lebih sedikit ruang rak - lebih banyak server yang dapat ditampung per unit ruang lantai dan oleh karena itu menurunkan biaya sewa.
Tetapi yang lebih penting adalah peningkatan kecepatan! Sekarang dengan 1U kita bisa memberikan lebih dari 100G! Dan ini dilatarbelakangi oleh situasi ketika beberapa proyek besar Rusia menyebut "pencapaian" kembalinya 40G dengan 2U. Kami akan menghadapi masalah mereka!
Perhatikan bahwa generasi kartu jaringan yang hanya dapat bekerja pada 10G, masih kami gunakan. Peralatan ini bekerja dengan stabil dan sangat familiar bagi kami, jadi kami tidak membuangnya, tetapi menemukan aplikasi baru untuk itu. Kami memasang komponen ini di server penyimpanan video, di mana satu atau dua antarmuka 1G jelas tidak cukup untuk pengoperasian yang efektif, di sini kartu 10G ternyata relevan.
Sistem penyimpanantumbuh juga. Selama lima tahun terakhir, mereka telah berubah dari dua belas-disk drive (12x HDD 2U) menjadi tiga puluh enam-disk drive (36x HDD 4U). Beberapa orang takut menggunakan "bangkai" yang begitu besar, karena jika salah satu sasis tersebut gagal, mungkin ada ancaman terhadap produktivitas - dan bahkan kapasitas kerja! - untuk seluruh sistem. Tetapi ini tidak akan terjadi pada kami: kami telah menyediakan cadangan pada tingkat salinan data yang terdistribusi secara geografis. Kami telah menyebarkan sasis ke berbagai pusat data - kami menggunakan total tiga - dan ini menghilangkan terjadinya masalah baik jika terjadi kegagalan sasis maupun saat platform jatuh.
Tentu saja, pendekatan ini membuat RAID perangkat keras menjadi tidak berguna, yang kami tinggalkan. Dengan menghilangkan redundansi, kami secara bersamaan meningkatkan keandalan sistem, menyederhanakan solusi, dan menghilangkan salah satu titik potensi kegagalan. Ingatlah bahwa sistem penyimpanan kami "buatan sendiri". Kami melakukan ini sepenuhnya dengan sengaja dan hasilnya sangat memuaskan bagi kami. Kami telah mengubah
pusat data beberapa kali selama lima tahun terakhir. Sejak penulisan artikel sebelumnya, kami tidak hanya mengubah satu pusat data - DataLine - sisanya memerlukan penggantian seiring dengan perkembangan infrastruktur kami. Semua transfer antar situs telah direncanakan.
Dua tahun lalu, kami bermigrasi di dalam MMTS-9, pindah ke lokasi dengan perbaikan berkualitas tinggi, sistem pendingin yang baik, catu daya yang stabil dan tanpa debu, yang biasanya berada di lapisan tebal di semua permukaan, dan juga menyumbat bagian dalam peralatan kami. Pilihlah layanan berkualitas - dan bebas debu! - menjadi alasan kami pindah.
Hampir selalu, "satu persimpangan sama dengan dua api", tetapi masalah migrasi berbeda setiap saat. Kali ini, kesulitan utama untuk berpindah ke dalam satu pusat data adalah "disediakan" oleh sambungan silang optik - sambungan silang yang berlimpah tanpa digabungkan menjadi sambungan silang tunggal oleh operator telekomunikasi. Proses pembaruan dan perutean ulang penyeberangan (yang dibantu oleh teknisi MMTS-9 kami) mungkin merupakan tahap migrasi yang paling sulit.
Migrasi kedua terjadi setahun yang lalu, pada 2019 kami pindah dari pusat data yang tidak terlalu bagus ke O2xygen. Alasan pemindahan serupa dengan yang dibahas di atas, tetapi ditambah dengan masalah ketidaktertarikan pusat data asli untuk operator telekomunikasi - banyak penyedia harus "mengejar" titik ini sendiri.
Migrasi 13 rak ke situs berkualitas tinggi di MMTS-9 memungkinkan untuk mengembangkan lokasi ini tidak hanya sebagai operator (beberapa rak dan operator "penerusan"), tetapi juga untuk menggunakannya sebagai salah satu yang utama. Ini agak menyederhanakan migrasi dari pusat data yang tidak terlalu bagus - kami memindahkan sebagian besar peralatan darinya ke situs lain, dan O2xygen mengambil peran untuk mengembangkan, mengirimkan 5 rak peralatan ke sana juga.
Saat ini O2xygen sudah menjadi platform yang lengkap, di mana operator yang kami butuhkan sudah โdatangโ dan yang baru terus terhubung. Bagi operator, O2xygen juga menarik dalam hal pengembangan strategis.
Kami pasti menghabiskan fase utama perpindahan dalam semalam, dan saat bermigrasi di dalam MMTS-9 dan ke O2xygen, kami mematuhi aturan ini. Kami ingin menekankan bahwa kami benar-benar mengikuti aturan "bergerak dalam semalam" berapa pun jumlah raknya! Bahkan ada preseden ketika kami memindahkan 20 rak dan melakukannya dalam satu malam juga. Migrasi adalah proses yang cukup sederhana yang membutuhkan akurasi dan konsistensi, namun ada beberapa trik di sini, baik dalam proses persiapan, maupun saat pindah, dan saat men-deploy ke lokasi baru. Kami siap memberi tahu Anda tentang migrasi secara detail jika Anda tertarik.
hasilKami menyukai rencana pengembangan lima tahun. Kami telah menyelesaikan pembangunan infrastruktur tangguh baru di tiga pusat data. Kami telah secara dramatis meningkatkan kepadatan pengiriman lalu lintas - jika kami baru-baru ini bersukacita di 40-80G dengan 2U, sekarang normal bagi kami untuk memberikan 100G dengan 1U. Sekarang satu terabit lalu lintas dianggap oleh kami sebagai hal yang biasa. Kami siap untuk mengembangkan lebih lanjut infrastruktur kami, yang ternyata fleksibel dan dapat diskalakan.
Pertanyaan:apa yang ingin Anda ceritakan dalam teks berikut, pembaca yang budiman? Mengapa kami mulai membangun sistem penyimpanan buatan sendiri? Tentang inti jaringan dan fitur-fiturnya? Tentang trik dan seluk-beluk migrasi antar pusat data? Tentang mengoptimalkan solusi penerbitan dengan memilih komponen dan parameter fine-tuning? Tentang menciptakan solusi berkelanjutan berkat beberapa redundansi dan skalabilitas horizontal dalam pusat data, yang diimplementasikan dalam struktur tiga pusat data?
Penulis: Petr Vinogradov - Direktur Teknis Uma.TechHamster