Web modern hampir tidak terpikirkan tanpa konten media: hampir setiap nenek memiliki ponsel cerdas, semua orang menggunakan jejaring sosial, dan waktu henti dalam pemeliharaan merugikan perusahaan. Berikut ini transkrip kisah perusahaan tentang bagaimana dia mengatur pengiriman foto menggunakan solusi perangkat keras, masalah kinerja apa yang dia temui dalam proses tersebut, apa penyebabnya, dan bagaimana masalah ini diselesaikan menggunakan solusi perangkat lunak berbasis Nginx, sekaligus memastikan toleransi kesalahan di semua tingkatan (). Kami berterima kasih kepada penulis cerita Oleg Efimova dan Alexandra Dymova, yang berbagi pengalaman mereka di konferensi tersebut .
— Mari kita mulai dengan sedikit perkenalan tentang cara kami menyimpan dan menyimpan foto dalam cache. Kami memiliki lapisan tempat kami menyimpannya, dan lapisan tempat kami menyimpan foto dalam cache. Pada saat yang sama, jika kita ingin mencapai tingkat trik yang tinggi dan mengurangi beban penyimpanan, penting bagi kita bahwa setiap foto pengguna individu berada di satu server cache. Jika tidak, kami harus memasang disk berkali-kali lebih banyak karena kami memiliki lebih banyak server. Tingkat trik kami sekitar 99%, yaitu, kami mengurangi beban penyimpanan kami sebanyak 100 kali lipat, dan untuk melakukan ini, 10 tahun yang lalu, ketika semua ini dibangun, kami memiliki 50 server. Oleh karena itu, untuk menyajikan foto-foto ini, kami pada dasarnya memerlukan 50 domain eksternal yang dilayani oleh server ini.
Tentu saja, pertanyaan segera muncul: jika salah satu server kami mati dan tidak tersedia, bagian lalu lintas manakah yang hilang? Kami melihat apa yang ada di pasaran dan memutuskan untuk membeli perangkat keras agar dapat menyelesaikan semua masalah kami. Pilihan jatuh pada solusi perusahaan jaringan F5 (yang baru saja membeli NGINX, Inc): BIG-IP Local Traffic Manager.
Apa yang dilakukan oleh perangkat keras (LTM) ini: ini adalah router besi yang membuat port eksternalnya menjadi redundansi besi dan memungkinkan Anda merutekan lalu lintas berdasarkan topologi jaringan, pada beberapa pengaturan, dan melakukan pemeriksaan kesehatan. Penting bagi kami bahwa perangkat keras ini dapat diprogram. Oleh karena itu, kami dapat menjelaskan logika bagaimana foto pengguna tertentu disajikan dari cache tertentu. Seperti apa bentuknya? Ada perangkat keras yang melihat Internet pada satu domain, satu IP, melakukan ssl offload, mem-parsing permintaan http, memilih nomor cache dari IRule, ke mana harus pergi, dan membiarkan lalu lintas menuju ke sana. Pada saat yang sama, ia melakukan pemeriksaan kesehatan, dan jika ada mesin yang tidak tersedia, pada saat itu kami mengatur agar lalu lintas menuju ke satu server cadangan. Dari sudut pandang konfigurasi, tentu saja ada beberapa nuansa, tetapi secara umum semuanya cukup sederhana: kami mendaftarkan kartu, korespondensi nomor tertentu dengan IP kami di jaringan, kami mengatakan bahwa kami akan mendengarkan pada port 80 dan 443, kami mengatakan bahwa jika server tidak tersedia, maka Anda perlu mengirim lalu lintas ke cadangan, dalam hal ini ke-35, dan kami menjelaskan banyak logika tentang bagaimana arsitektur ini harus dibongkar. Satu-satunya masalah adalah bahasa yang digunakan untuk memprogram perangkat keras adalah Tcl. Jika ada yang mengingat ini... bahasa ini lebih hanya untuk menulis daripada bahasa yang nyaman untuk pemrograman:
Apa yang kami dapatkan? Kami menerima perangkat keras yang memastikan ketersediaan infrastruktur kami, mengarahkan semua lalu lintas kami, memberikan manfaat kesehatan, dan berfungsi dengan baik. Apalagi cara kerjanya cukup lama: selama 10 tahun terakhir tidak ada keluhan tentangnya. Pada awal tahun 2018, kami telah mengirimkan sekitar 80 ribu foto per detik. Ini berarti lalu lintas sekitar 80 gigabit dari kedua pusat data kami.
Tapi…
Pada awal tahun 2018, kami melihat gambaran buruk di tangga lagu: waktu yang dibutuhkan untuk mengirim foto jelas meningkat. Dan itu tidak lagi cocok untuk kita. Masalahnya adalah perilaku ini hanya terlihat pada puncak lalu lintas - bagi perusahaan kami ini adalah malam dari Minggu hingga Senin. Namun selebihnya sistem berperilaku seperti biasa, tidak ada tanda-tanda kegagalan.
Meski begitu, masalah tersebut harus diselesaikan. Kami mengidentifikasi kemungkinan hambatan dan mulai menghilangkannya. Pertama-tama, tentu saja, kami memperluas uplink eksternal, melakukan audit menyeluruh terhadap uplink internal, dan menemukan semua kemungkinan hambatan. Namun semua itu tidak memberikan hasil yang jelas, masalahnya tidak hilang.
Kemacetan lain yang mungkin terjadi adalah kinerja cache foto itu sendiri. Dan kami memutuskan bahwa mungkin masalahnya ada pada mereka. Ya, kami memperluas kinerja - terutama port jaringan pada cache foto. Namun sekali lagi, tidak ada perbaikan nyata yang terlihat. Pada akhirnya, kami memperhatikan dengan cermat kinerja LTM itu sendiri, dan di sini kami melihat gambaran menyedihkan pada grafik: beban pada semua CPU mulai berjalan lancar, tetapi kemudian tiba-tiba mencapai titik tertinggi. Pada saat yang sama, LTM berhenti merespons pemeriksaan kesehatan dan uplink secara memadai dan mulai menonaktifkannya secara acak, yang menyebabkan penurunan kinerja yang serius.
Artinya, kami telah mengidentifikasi sumber masalahnya, mengidentifikasi hambatannya. Tinggal memutuskan apa yang akan kami lakukan.
Hal pertama dan paling jelas yang dapat kami lakukan adalah memodernisasi LTM itu sendiri. Namun ada beberapa perbedaan disini, karena hardware ini cukup unik, Anda tidak perlu pergi ke supermarket terdekat dan membelinya. Ini adalah kontrak terpisah, kontrak lisensi terpisah, dan ini akan memakan banyak waktu. Pilihan kedua adalah mulai berpikir sendiri, temukan solusi Anda sendiri menggunakan komponen Anda sendiri, sebaiknya menggunakan program akses terbuka. Yang tersisa hanyalah memutuskan apa sebenarnya yang akan kami pilih untuk ini dan berapa banyak waktu yang akan kami habiskan untuk menyelesaikan masalah ini, karena pengguna tidak menerima cukup foto. Oleh karena itu, kita perlu melakukan semua ini dengan sangat-sangat cepat, bisa dikatakan kemarin.
Karena tugasnya terdengar seperti “melakukan sesuatu secepat mungkin dan menggunakan perangkat keras yang kami miliki”, hal pertama yang kami pikirkan adalah menghapus beberapa mesin yang tidak terlalu kuat dari depan, meletakkan Nginx di sana, yang kami tahu caranya. bekerja dan mencoba menerapkan semua logika yang sama seperti yang biasa dilakukan perangkat keras. Faktanya, kami meninggalkan perangkat keras kami, memasang 4 server lagi yang harus kami konfigurasi, membuat domain eksternal untuk mereka, mirip dengan 10 tahun yang lalu... Kami kehilangan sedikit ketersediaan jika mesin ini jatuh, tapi apalagi, mereka memecahkan masalah pengguna kami secara lokal.
Oleh karena itu, logikanya tetap sama: kita menginstal Nginx, ia dapat melakukan SSL-offload, entah bagaimana kita dapat memprogram logika perutean, memeriksa kondisi konfigurasi, dan cukup menduplikasi logika yang kita miliki sebelumnya.
Mari kita duduk untuk menulis konfigurasi. Pada awalnya tampaknya semuanya sangat sederhana, namun sayangnya, sangat sulit menemukan manual untuk setiap tugas. Oleh karena itu, kami tidak menyarankan untuk hanya mencari di Google “cara mengkonfigurasi Nginx untuk foto”: lebih baik mengacu pada dokumentasi resmi, yang akan menunjukkan pengaturan mana yang harus disentuh. Namun lebih baik memilih sendiri parameter spesifiknya. Baiklah, semuanya sederhana: kami menjelaskan server yang kami miliki, kami menjelaskan sertifikatnya... Namun yang paling menarik sebenarnya adalah logika perutean itu sendiri.
Pada awalnya kami merasa bahwa kami hanya menggambarkan lokasi kami, mencocokkan jumlah cache foto kami di dalamnya, menggunakan tangan kami atau generator untuk menggambarkan berapa banyak upstream yang kami butuhkan, di setiap upstream kami menunjukkan server ke mana lalu lintas harus pergi, dan server cadangan - jika server utama tidak tersedia:
Tapi, mungkin, jika semuanya sesederhana itu, kami akan pulang begitu saja dan tidak mengatakan apa pun. Sayangnya, dengan pengaturan default Nginx, yang, secara umum, dibuat selama bertahun-tahun pengembangan dan tidak sepenuhnya cocok untuk kasus ini... konfigurasinya terlihat seperti ini: jika beberapa server upstream mengalami kesalahan permintaan atau batas waktu, Nginx selalu mengalihkan lalu lintas ke yang berikutnya. Selain itu, setelah kegagalan pertama, dalam 10 detik server juga akan dimatikan, baik karena kesalahan maupun batas waktu - ini bahkan tidak dapat dikonfigurasi dengan cara apa pun. Artinya, jika kita menghapus atau mengatur ulang opsi batas waktu di direktif upstream, meskipun Nginx tidak akan memproses permintaan ini dan akan merespons dengan beberapa kesalahan yang tidak terlalu bagus, server akan dimatikan.
Untuk menghindari hal ini, kami melakukan dua hal:
a) mereka melarang Nginx melakukan ini secara manual - dan sayangnya, satu-satunya cara untuk melakukan ini adalah dengan mengatur pengaturan max failed.
b) kami ingat bahwa di proyek lain kami menggunakan modul yang memungkinkan kami melakukan pemeriksaan kesehatan latar belakang - oleh karena itu, kami melakukan pemeriksaan kesehatan cukup sering sehingga waktu henti jika terjadi kecelakaan akan minimal.
Sayangnya, ini belum semuanya, karena dua minggu pertama pengoperasian skema ini menunjukkan bahwa pemeriksaan kesehatan TCP juga merupakan hal yang tidak dapat diandalkan: di server upstream mungkin bukan Nginx, atau Nginx di status-D, dan di dalam hal ini kernel akan menerima koneksi, pemeriksaan kesehatan akan lolos, tetapi tidak akan berfungsi. Oleh karena itu, kami segera menggantinya dengan http cek kesehatan, membuat yang spesifik, yang jika mengembalikan 200, maka semuanya berfungsi di skrip ini. Anda dapat melakukan logika tambahan - misalnya, dalam kasus server caching, periksa apakah sistem file sudah terpasang dengan benar:
Dan ini cocok untuk kita, kecuali bahwa pada saat ini rangkaian tersebut sepenuhnya mengulangi apa yang dilakukan perangkat keras. Namun kami ingin melakukan yang lebih baik. Sebelumnya, kami memiliki satu server cadangan, dan ini mungkin tidak terlalu bagus, karena jika Anda memiliki seratus server, maka jika beberapa server gagal sekaligus, satu server cadangan kemungkinan besar tidak akan mampu mengatasi beban tersebut. Oleh karena itu, kami memutuskan untuk mendistribusikan reservasi ke semua server: kami cukup membuat upstream terpisah lainnya, menulis semua server di sana dengan parameter tertentu sesuai dengan beban yang dapat mereka layani, menambahkan pemeriksaan kesehatan yang sama seperti yang kami lakukan sebelumnya :
Karena tidak mungkin untuk pergi ke upstream lain dalam satu upstream, penting untuk memastikan bahwa jika upstream utama, di mana kami hanya mencatat cache foto yang benar dan diperlukan, tidak tersedia, kami cukup membuka halaman_kesalahan untuk melakukan fallback, dari tempat kami pergi ke hulu cadangan:
Dan dengan menambahkan empat server, inilah yang kami dapatkan: kami mengganti sebagian beban - kami menghapusnya dari LTM ke server ini, menerapkan logika yang sama di sana, menggunakan perangkat keras dan perangkat lunak standar, dan segera menerima bonus yang dapat dilakukan server ini. ditingkatkan, karena mereka dapat dengan mudah disuplai sebanyak yang dibutuhkan. Satu-satunya hal negatifnya adalah kami kehilangan ketersediaan tinggi untuk pengguna eksternal. Namun saat itu kami harus mengorbankan hal tersebut, karena masalah tersebut perlu segera diselesaikan. Jadi, kami menghapus sebagian beban, saat itu sekitar 40%, LTM terasa baik, dan dua minggu setelah masalah dimulai, kami mulai mengirim bukan 45 ribu permintaan per detik, tetapi 55 ribu. Faktanya, kami tumbuh sebesar 20% - ini jelas merupakan lalu lintas yang tidak kami berikan kepada pengguna. Dan setelah itu mereka mulai memikirkan bagaimana menyelesaikan masalah yang tersisa - untuk memastikan aksesibilitas eksternal yang tinggi.
Kami mengambil jeda sejenak, dan pada saat itu kami mendiskusikan solusi apa yang akan kami gunakan untuk mengatasi masalah ini. Ada proposal untuk memastikan keandalan menggunakan DNS, dengan bantuan beberapa skrip buatan sendiri, protokol perutean dinamis... ada banyak pilihan, tetapi sudah menjadi jelas bahwa untuk pengiriman foto yang benar-benar andal, Anda perlu memperkenalkan lapisan lain yang akan memantau ini. Kami menyebut mesin ini sebagai pengarah foto. Perangkat lunak yang kami andalkan adalah Keepalived:
Pertama-tama, Keepalived terdiri dari apa? Yang pertama adalah protokol VRRP, yang dikenal luas oleh para penggiat jaringan, terletak pada peralatan jaringan yang memberikan toleransi kesalahan pada alamat IP eksternal yang terhubung dengan klien. Bagian kedua adalah IPVS, server virtual IP, untuk menyeimbangkan antara router foto dan memastikan toleransi kesalahan pada tingkat ini. Dan yang ketiga adalah pemeriksaan kesehatan.
Mari kita mulai dengan bagian pertama: VRRP - seperti apa bentuknya? Ada IP virtual tertentu, yang memiliki entri di dns badoocdn.com, tempat klien terhubung. Pada suatu saat, kami memiliki alamat IP di satu server. Paket yang disimpan dijalankan antar server menggunakan protokol VRRP, dan jika master menghilang dari radar - server telah di-boot ulang atau yang lainnya, maka server cadangan secara otomatis mengambil alamat IP ini - tidak diperlukan tindakan manual. Perbedaan antara master dan cadangan terutama terletak pada prioritas: semakin tinggi prioritasnya, semakin besar peluang mesin menjadi master. Keuntungan yang sangat besar adalah Anda tidak perlu mengonfigurasi alamat IP di server itu sendiri, cukup menjelaskannya di konfigurasi, dan jika alamat IP memerlukan beberapa aturan perutean khusus, ini dijelaskan langsung di konfigurasi, menggunakan sintaks yang sama seperti yang dijelaskan dalam paket VRRP. Anda tidak akan menemui hal-hal asing.
Seperti apa praktiknya? Apa yang terjadi jika salah satu server gagal? Segera setelah master menghilang, cadangan kami berhenti menerima iklan dan secara otomatis menjadi master. Setelah beberapa waktu, kami memperbaiki master, mem-boot ulang, menaikkan Keepalive - iklan datang dengan prioritas lebih tinggi daripada cadangan, dan cadangan secara otomatis kembali, menghapus alamat IP, tidak ada tindakan manual yang perlu dilakukan.
Dengan demikian, kami telah memastikan toleransi kesalahan alamat IP eksternal. Bagian selanjutnya adalah menyeimbangkan lalu lintas dari alamat IP eksternal ke router foto yang sudah menghentikannya. Semuanya cukup jelas dengan protokol penyeimbangan. Ini bisa berupa round-robin sederhana, atau hal-hal yang sedikit lebih rumit, wrr, koneksi daftar, dan sebagainya. Ini pada dasarnya dijelaskan dalam dokumentasi, tidak ada yang istimewa. Tapi metode pengirimannya... Di sini kita akan melihat lebih dekat mengapa kami memilih salah satunya. Ini adalah NAT, Perutean Langsung, dan TUN. Faktanya adalah kami segera merencanakan untuk memberikan 100 gigabit lalu lintas dari situs tersebut. Kalau perkiraannya butuh 10 gigabit card kan? 10 kartu gigabit dalam satu server sudah di luar cakupan, setidaknya, konsep kami tentang “peralatan standar”. Dan kemudian kami ingat bahwa kami tidak hanya memberikan lalu lintas, kami juga memberikan foto.
Apa yang istimewa? — Perbedaan besar antara lalu lintas masuk dan keluar. Lalu lintas masuk sangat kecil, lalu lintas keluar sangat besar:
Jika Anda melihat grafik ini, Anda dapat melihat bahwa saat ini sutradara menerima sekitar 200 MB per detik, ini adalah hari yang sangat biasa. Kami mengembalikan 4,500 MB per detik, rasio kami kira-kira 1/22. Sudah jelas bahwa untuk sepenuhnya menyediakan lalu lintas keluar ke 22 server pekerja, kita hanya memerlukan satu server yang menerima koneksi ini. Di sinilah algoritma perutean langsung membantu kami.
Seperti apa bentuknya? Direktur foto kami, menurut tabelnya, mentransmisikan koneksi ke router foto. Tetapi router foto mengirimkan lalu lintas balik langsung ke Internet, mengirimkannya ke klien, tidak kembali melalui pengarah foto, jadi, dengan jumlah mesin minimum, kami memastikan toleransi kesalahan sepenuhnya dan pemompaan semua lalu lintas. Dalam konfigurasinya terlihat seperti ini: kami menentukan algoritme, dalam kasus kami ini adalah rr sederhana, menyediakan metode perutean langsung dan kemudian mulai membuat daftar semua server sebenarnya, berapa banyak yang kami miliki. Yang akan menentukan lalu lintas ini. Jika kita memiliki satu atau dua server lagi, atau beberapa server, kebutuhan seperti itu muncul - kita cukup menambahkan bagian ini ke konfigurasi dan jangan terlalu khawatir. Dari sisi server nyata, dari sisi router foto, metode ini memerlukan konfigurasi paling minimal, dijelaskan dengan sempurna dalam dokumentasi, dan tidak ada jebakan di sana.
Hal yang sangat menarik adalah bahwa solusi seperti itu tidak berarti mendesain ulang jaringan lokal secara radikal; ini penting bagi kami; kami harus menyelesaikannya dengan biaya minimal. Jika Anda melihat , lalu kita lihat seperti apa. Di sini kita memiliki server virtual tertentu, pada port 443, mendengarkan, menerima koneksi, semua server yang berfungsi terdaftar, dan Anda dapat melihat bahwa koneksinya, memberi atau menerima, sama. Jika kita melihat statistik pada server virtual yang sama, kita memiliki paket masuk, koneksi masuk, tapi sama sekali tidak ada paket keluar. Koneksi keluar langsung ke klien. Oke, kami bisa membuat ketidakseimbangannya. Sekarang, apa yang terjadi jika salah satu router foto kita rusak? Bagaimanapun, besi tetaplah besi. Ini mungkin menyebabkan kepanikan kernel, mungkin rusak, dan catu daya mungkin terbakar. Apa pun. Inilah sebabnya mengapa pemeriksaan kesehatan diperlukan. Hal ini bisa sesederhana memeriksa bagaimana port terbuka, atau sesuatu yang lebih rumit, hingga beberapa skrip buatan sendiri yang bahkan akan memeriksa logika bisnis.
Kami berhenti di suatu tempat di tengah: kami memiliki permintaan https ke lokasi tertentu, skrip dipanggil, jika merespons dengan respons ke-200, kami yakin semuanya baik-baik saja dengan server ini, masih hidup dan dapat dihidupkan sepenuhnya dengan mudah.
Sekali lagi, bagaimana hal ini terlihat dalam praktiknya? Mari kita matikan server untuk pemeliharaan - mem-flash BIOS, misalnya. Di log, kami segera mendapat batas waktu, kami melihat baris pertama, kemudian setelah tiga kali mencoba ditandai sebagai "gagal", dan dihapus begitu saja dari daftar.
Opsi perilaku kedua juga dimungkinkan, ketika VS disetel ke nol, tetapi jika foto dikembalikan, ini tidak berfungsi dengan baik. Server muncul, Nginx mulai di sana, pemeriksaan kesehatan segera memahami bahwa koneksi berfungsi, semuanya baik-baik saja, dan server muncul di daftar kami, dan beban segera mulai diterapkan padanya. Tidak ada tindakan manual yang diperlukan dari administrator tugas. Server di-boot ulang pada malam hari - departemen pemantauan tidak menghubungi kami tentang hal ini pada malam hari. Mereka memberi tahu Anda bahwa ini terjadi, semuanya baik-baik saja.
Jadi, dengan cara yang cukup sederhana, dengan bantuan sejumlah kecil server, kami memecahkan masalah toleransi kesalahan eksternal.
Hanya saja, semua ini tentu saja perlu diawasi. Secara terpisah, perlu dicatat bahwa Keepalivede, sebagai perangkat lunak yang ditulis sejak lama, memiliki banyak cara untuk memantaunya, baik menggunakan pemeriksaan melalui DBus, SMTP, SNMP, dan Zabbix standar. Ditambah lagi, dia sendiri tahu cara menulis surat untuk hampir setiap bersin, dan sejujurnya, pada titik tertentu kami bahkan berpikir untuk mematikannya, karena dia menulis banyak surat untuk setiap peralihan lalu lintas, pengaktifan, untuk setiap koneksi IP, dan seterusnya. Tentu saja, jika servernya banyak, Anda bisa kewalahan dengan surat-surat ini. Kami memantau nginx di router foto menggunakan metode standar, dan pemantauan perangkat keras terus berlanjut. Tentu saja kami akan menyarankan dua hal lagi: pertama, pemeriksaan kesehatan eksternal dan ketersediaan, karena meskipun semuanya berfungsi, pada kenyataannya, pengguna mungkin tidak menerima foto karena masalah dengan penyedia eksternal atau sesuatu yang lebih kompleks. Sebaiknya simpan di suatu tempat di jaringan lain, di Amazon atau di tempat lain, mesin terpisah yang dapat melakukan ping ke server Anda dari luar, dan ada baiknya juga menggunakan deteksi anomali, bagi mereka yang tahu cara melakukan pembelajaran mesin yang rumit, atau pemantauan sederhana , setidaknya untuk melacak apakah permintaan menurun tajam, atau sebaliknya meningkat. Ini juga bisa bermanfaat.
Mari kita rangkum: kami, pada kenyataannya, mengganti solusi berlapis besi, yang pada titik tertentu tidak lagi cocok untuk kami, dengan sistem yang cukup sederhana yang melakukan semuanya sama, yaitu menyediakan penghentian lalu lintas HTTPS dan perutean cerdas lebih lanjut dengan pemeriksaan kesehatan yang diperlukan. Kami telah meningkatkan stabilitas sistem ini, yaitu, kami masih memiliki ketersediaan yang tinggi untuk setiap lapisan, ditambah lagi kami mendapat bonus bahwa cukup mudah untuk menskalakan semuanya di setiap lapisan, karena ini adalah perangkat keras standar dengan perangkat lunak standar, yaitu , kami telah menyederhanakan diagnosis kemungkinan masalah.
Apa yang akhirnya kita dapatkan? Kami mengalami masalah selama liburan Januari 2018. Dalam enam bulan pertama saat kami menerapkan skema ini, kami memperluasnya ke semua lalu lintas untuk menghapus semua lalu lintas dari LTM, kami hanya meningkatkan lalu lintas di satu pusat data dari 40 gigabit menjadi 60 gigabit, dan pada saat yang sama untuk sepanjang tahun 2018 mampu mengirim foto hampir tiga kali lebih banyak per detik.
Sumber: www.habr.com