Web modern meh ora bisa dipikirake tanpa konten media: meh saben nenek duwe smartphone, kabeh wong ana ing jaringan sosial, lan downtime ing pangopènan larang regane kanggo perusahaan. Punika transkrip crita perusahaan babagan carane dheweke ngatur pangiriman foto nggunakake solusi hardware, apa masalah kinerja sing ditemoni ing proses kasebut, apa sing nyebabake, lan carane masalah kasebut ditanggulangi kanthi nggunakake solusi piranti lunak adhedhasar Nginx, nalika njamin toleransi kesalahan ing kabeh level (). Kita matur nuwun marang penulis crita Oleg Efimova lan Alexandra Dymova, sing nuduhake pengalaman ing konferensi kasebut .
— Ayo dadi miwiti karo introduksi sethitik bab carane kita nyimpen lan cache foto. Kita duwe lapisan ing ngendi kita nyimpen, lan lapisan ing ngendi kita nyimpen foto kasebut. Ing wektu sing padha, yen kita pengin entuk tingkat trick sing dhuwur lan nyuda beban ing panyimpenan, penting kanggo kita yen saben foto pangguna individu ana ing siji server caching. Yen ora, kita kudu nginstal luwih akeh disk amarga kita duwe luwih akeh server. Tingkat trik kita udakara 99%, yaiku, kita nyuda beban ing panyimpenan kaping 100, lan kanggo nindakake iki, 10 taun kepungkur, nalika kabeh iki dibangun, kita duwe 50 server. Dadi, kanggo ngladeni foto kasebut, kita butuh 50 domain eksternal sing dilayani dening server kasebut.
Mesthi wae, pitakonan langsung muncul: yen salah siji saka server kita mudhun lan ora kasedhiya, apa bagean saka lalu lintas sing ilang? Kita ndeleng apa sing ana ing pasar lan mutusake kanggo tuku piranti keras supaya bisa ngatasi kabeh masalah kita. Pilihan kasebut ana ing solusi saka perusahaan jaringan F5 (sing, kanthi cara, bubar tuku NGINX, Inc): Manajer Lalu Lintas Lokal BIG-IP.
Apa hardware iki (LTM) nindakake: iku router wesi sing nggawe redundansi wesi saka port external lan ngijini sampeyan kanggo rute lalu lintas adhedhasar topologi jaringan, ing sawetara setelan, lan mriksa kesehatan. Penting kanggo kita manawa piranti keras iki bisa diprogram. Mulane, kita bisa njlèntrèhaké logika carane foto pangguna tartamtu dilayani saka cache tartamtu. Apa sing katon? Ana Piece saka hardware sing katon ing Internet ing siji domain, siji IP, apa ssl offload, parses http panjalukan, milih nomer cache saka IRule, ngendi kanggo pindhah, lan ngijini lalu lintas menyang kono. Ing wektu sing padha, iku nindakake mriksa kesehatan, lan ing acara saka sawetara mesin ora kasedhiya, ing wektu iku kita digawe supaya lalu lintas menyang siji server serep. Saka sudut pandang konfigurasi, mesthi ana sawetara nuansa, nanging umume kabeh cukup prasaja: kita ndhaptar kertu, korespondensi nomer tartamtu menyang IP kita ing jaringan, kita ngomong yen kita bakal ngrungokake port 80 lan 443, kita ngomong yen server ora kasedhiya, sampeyan kudu ngirim lalu lintas menyang serep, ing kasus iki 35, lan kita njlèntrèhaké Bunch saka logika carane arsitektur iki kudu disassembled. Masalah mung yaiku basa ing ngendi hardware diprogram yaiku Tcl. Yen ana sing ngelingi iki ... basa iki luwih mung nulis tinimbang basa sing trep kanggo pemrograman:
Apa sing kita entuk? Kita nampa bagean saka hardware sing njamin kasedhiyan dhuwur saka infrastruktur kita, rute kabeh lalu lintas kita, menehi keuntungan kesehatan lan mung dianggo. Kajaba iku, kerjane cukup suwe: sajrone 10 taun kepungkur, ora ana keluhan babagan iki. Ing wiwitan taun 2018, kita wis ngirim udakara 80k foto saben detik. Iki ana ing sekitar 80 gigabit lalu lintas saka loro pusat data kita.
Nanging…
Ing wiwitan taun 2018, kita ndeleng gambar sing ala ing tangga lagu: wektu sing dibutuhake kanggo ngirim foto wis tambah akeh. Lan mandheg cocog karo kita. Masalahe yaiku prilaku iki mung katon nalika puncak lalu lintas - kanggo perusahaan kita iki wengi saka Minggu nganti Senin. Nanging wektu liyane sistem tumindak kaya biasane, ora ana tandha-tandha gagal.
Nanging, masalah kasebut kudu dirampungake. Kita nemtokake kemungkinan bottlenecks lan wiwit ngilangi. Kaping pisanan, mesthi, kita nggedhekake uplink eksternal, nganakake audit lengkap babagan uplink internal, lan nemokake kabeh kemungkinan bottlenecks. Nanging kabeh iki ora menehi asil sing jelas, masalah kasebut ora ilang.
Kemacetan liyane sing bisa ditindakake yaiku kinerja cache foto kasebut. Lan kita mutusake manawa masalah kasebut ana ing dheweke. Ya, kita nggedhekake kinerja - utamane port jaringan ing cache foto. Nanging maneh ora ana perbaikan sing jelas. Pungkasan, kita mbayar manungsa waé kanggo kinerja LTM dhewe, lan ing kene kita ndeleng gambar sedih ing grafik: beban ing kabeh CPU wiwit lancar, nanging dumadakan teka ing plato. Ing wektu sing padha, LTM mandheg nanggapi kanthi cukup kanggo mriksa kesehatan lan uplinks lan wiwit mateni kanthi acak, sing nyebabake degradasi kinerja sing serius.
Sing, kita wis dikenali sumber masalah, dikenali bottleneck. Iku tetep kanggo mutusake apa sing bakal kita lakoni.
Sing pertama, sing paling jelas sing bisa ditindakake yaiku modernisasi LTM dhewe. Nanging ana sawetara nuansa ing kene, amarga hardware iki cukup unik, sampeyan ora bakal pindhah menyang supermarket paling cedhak lan tuku. Iki kontrak kapisah, kontrak lisensi kapisah, lan bakal njupuk akèh wektu. Opsi kapindho yaiku miwiti mikir dhewe, nggawe solusi sampeyan nggunakake komponen sampeyan dhewe, luwih becik nggunakake program akses mbukak. Kabeh sing isih ana yaiku mutusake apa sing bakal kita pilih kanggo iki lan sepira wektu sing bakal ditindakake kanggo ngrampungake masalah iki, amarga pangguna ora nampa foto sing cukup. Mula, kita kudu nindakake kabeh iki kanthi cepet, bisa uga ujar wingi.
Amarga tugas kasebut kaya "nindakake apa wae kanthi cepet lan nggunakake piranti keras sing kita duwe," sing pertama kita pikirake yaiku mbusak sawetara mesin sing ora kuat saka ngarep, sijine Nginx ing kana, sing kita ngerti carane bisa lan nyoba kanggo ngleksanakake kabeh logika padha hardware digunakake kanggo nindakake. Yaiku, nyatane, kita ninggalake hardware kita, nginstal 4 server liyane sing kudu dikonfigurasi, nggawe domain eksternal kanggo wong-wong mau, padha kaya 10 taun kepungkur ... Kita ilang sethithik kasedhiya yen mesin kasebut tiba, nanging isih kurang, padha ditanggulangi masalah kita kedhaftar lokal.
Patut, logika tetep padha: kita nginstal Nginx, bisa nindakake SSL-offload, kita bisa piye wae program logika nuntun, kesehatan-mriksa ing configs lan mung duplikat logika kita wis sadurunge.
Ayo lungguh kanggo nulis konfigurasi. Ing kawitan iku ketoke sing kabeh iku banget prasaja, nanging, sayangé, iku angel banget kanggo golek manual kanggo saben tugas. Mula, kita ora nyaranake mung googling "carane ngatur Nginx kanggo foto": luwih becik ngrujuk menyang dokumentasi resmi, sing bakal nuduhake setelan sing kudu didemek. Nanging luwih apik kanggo milih parameter tartamtu dhewe. Inggih, kabeh iku prasaja: kita njlèntrèhaké server sing kita duwe, kita njlèntrèhaké sertifikat ... Nanging sing paling menarik, nyatane, logika routing dhewe.
Kaping pisanan, kita mung njlentrehake lokasi kita, cocog karo jumlah cache foto kita, nggunakake tangan utawa generator kanggo njlèntrèhaké pinten hulu sing kita butuhake, ing saben hulu kita nuduhake server sing kudu dilalui. pindhah, lan server serep - yen server utama ora kasedhiya:
Nanging, mbokmenawa, yen kabeh prasaja, kita mung bakal mulih lan ora ngomong apa-apa. Sayange, kanthi setelan Nginx standar, sing umume digawe sajrone pirang-pirang taun pembangunan lan ora cocog kanggo kasus iki ... konfigurasi katon kaya iki: yen sawetara server hulu duwe kesalahan panyuwunan utawa wektu entek, Nginx tansah ngalih lalu lintas menyang sabanjure. Kajaba iku, sawise gagal pisanan, ing 10 detik, server uga bakal dipateni, kanthi salah lan wektu entek - iki ora bisa dikonfigurasi kanthi cara apa wae. Yaiku, yen kita mbusak utawa ngreset pilihan wektu entek ing arahan hulu, mula, sanajan Nginx ora bakal ngolah panjaluk iki lan bakal nanggapi sawetara kesalahan sing ora apik, server bakal mati.
Kanggo ngindhari iki, kita nindakake rong perkara:
a) padha nglarang Nginx nindakake iki kanthi manual - lan sayangé, siji-sijine cara kanggo nindakake iki yaiku mung nyetel setelan gagal maksimal.
b) kita eling yen ing proyek liyane, kita nggunakake modul sing ngidini kita nindakake pemeriksaan kesehatan latar mburi - kanthi mangkono, kita nindakake pemeriksaan kesehatan sing cukup kerep supaya downtime yen ana kacilakan bakal minimal.
Sayange, iki ora kabeh, amarga secara harfiah rong minggu pisanan operasi skema iki nuduhake manawa mriksa kesehatan TCP uga ora bisa dipercaya: ing server hulu bisa uga ora Nginx, utawa Nginx ing D-state, lan ing kasus iki kernel bakal nampa sambungan, mriksa kesehatan bakal pass, nanging ora bisa. Mulane, kita langsung ngganti iki karo kesehatan-mriksa http, digawe siji tartamtu, kang, yen bali 200, banjur kabeh dianggo ing script iki. Sampeyan bisa nindakake logika tambahan - contone, ing kasus server caching, priksa manawa sistem file wis dipasang kanthi bener:
Lan iki bakal cocog karo kita, kajaba ing wayahe sirkuit rampung mbaleni apa hardware. Nanging kita pengin luwih apik. Sadurunge, kita duwe siji server serep, lan iki mbokmenawa ora apik banget, amarga yen sampeyan duwe satus server, banjur nalika sawetara gagal bebarengan, siji server serep iku dipercaya kanggo ngrampungake karo mbukak. Mulane, kita mutusake kanggo nyebarake reservasi ing kabeh server: kita mung nggawe hulu kapisah liyane, nulis kabeh server ing kana kanthi paramèter tartamtu sesuai karo beban sing bisa dilayani, nambahake pemeriksaan kesehatan sing padha sadurunge:
Amarga ora bisa pindhah menyang hulu liyane ing siji hulu, perlu kanggo mesthekake yen hulu utama, ing ngendi kita mung nyathet cache foto sing bener lan perlu, ora kasedhiya, kita mung ngliwati error_page kanggo mundur, saka ngendi kita tindak menyang upstream cadangan:
Lan kanthi harfiah nambahake papat server, iki sing entuk: kita ngganti bagean beban - kita mbusak saka LTM menyang server kasebut, ngetrapake logika sing padha ing kana, nggunakake hardware lan piranti lunak standar, lan langsung nampa bonus sing bisa ditindakake dening server kasebut. ukuran, amarga padha bisa mung sumber minangka akeh sing perlu. Inggih, mung negatif yaiku kita wis ilang kasedhiyan dhuwur kanggo pangguna eksternal. Nanging ing wayahe kita kudu kurban iki, amarga iku perlu kanggo ngatasi masalah langsung. Dadi, kita mbusak bagean saka beban kasebut, kira-kira 40% ing wektu kasebut, LTM rumangsa apik, lan secara harfiah rong minggu sawise masalah kasebut diwiwiti, kita wiwit ngirim ora 45k panjalukan per detik, nanging 55k. Nyatane, kita tambah 20% - iki jelas lalu lintas sing ora diwenehake marang pangguna. Lan sawise iku padha wiwit mikir babagan carane ngatasi masalah isih - kanggo mesthekake aksesibilitas external dhuwur.
Kita duwe sawetara ngaso, sajrone kita ngrembug solusi apa sing bakal digunakake kanggo iki. Ana usulan-usulan kanggo mesthekake linuwih nggunakake DNS, kanthi bantuan saka sawetara script ngarep-ditulis, protokol routing dinamis ... ana akeh opsi, nanging wis dadi cetha yen kanggo pangiriman saestu dipercaya saka foto, sampeyan kudu introduce lapisan liyane sing bakal ngawasi iki. Kita disebut direktur foto mesin iki. Piranti lunak sing diandelake yaiku Keepalived:
Kanggo miwiti, apa isine Keepalived? Kapisan yaiku protokol VRRP, sing dikenal umum kanggo para jaringan, dumunung ing peralatan jaringan sing nyedhiyakake toleransi kesalahan menyang alamat IP eksternal sing disambungake klien. Bagian kapindho yaiku IPVS, server virtual IP, kanggo ngimbangi antarane router foto lan njamin toleransi kesalahan ing level iki. Lan katelu - mriksa kesehatan.
Ayo miwiti karo bagean pisanan: VRRP - kaya apa? Ana IP virtual tartamtu, sing nduweni entri ing dns badoocdn.com, ing ngendi klien nyambung. Ing sawetara wektu, kita duwe alamat IP ing siji server. Paket Keepalived mbukak ing antarane server nggunakake protokol VRRP, lan yen master ilang saka radar - server wis reboot utawa liyane, banjur server serep kanthi otomatis njupuk alamat IP iki - ora perlu tumindak manual. Bentenipun antarane master lan serep utamané prioritas: sing luwih dhuwur iku, luwih gedhe kasempatan sing mesin bakal dadi master. A kauntungan gedhe banget sing ora perlu kanggo ngatur alamat IP ing server dhewe, iku cukup kanggo njlèntrèhaké ing config, lan yen alamat IP perlu sawetara aturan nuntun adat, iki diterangake langsung ing config, nggunakake sintaks padha kaya sing diterangake ing paket VRRP. Sampeyan ora bakal nemoni samubarang sing ora pati ngerti.
Apa iki katon kaya ing laku? Apa sing kedadeyan yen salah sawijining server gagal? Sanalika master ilang, cadangan kita mandheg nampa pariwara lan kanthi otomatis dadi master. Sawise sawetara wektu, kita ndandani master, reboot, wungu Keepalived - iklan teka kanthi prioritas sing luwih dhuwur tinimbang serep, lan serep kanthi otomatis mundur, mbusak alamat IP, ora ana tindakan manual sing kudu ditindakake.
Mangkono, kita wis njamin toleransi kesalahan alamat IP eksternal. Bagian sabanjure yaiku kanggo ngimbangi lalu lintas saka alamat IP eksternal menyang router foto sing wis mandheg. Kabeh cukup jelas karo protokol balancing. Iki minangka round-robin sing prasaja, utawa barang sing rada rumit, wrr, sambungan dhaptar lan liya-liyane. Iki Sejatine diterangake ing dokumentasi, ana apa-apa khusus. Nanging cara pangiriman ... Ing kene kita bakal nliti kanthi luwih rinci kenapa kita milih salah sijine. Iki NAT, Direct Routing lan TUN. Kasunyatane yaiku kita langsung ngrancang ngirim 100 gigabit lalu lintas saka situs kasebut. Yen sampeyan ngira, sampeyan butuh 10 kertu gigabit, ta? 10 kertu gigabit ing siji server wis ngluwihi ruang lingkup, paling ora, konsep "peralatan standar". Banjur kita eling yen kita ora mung menehi sawetara lalu lintas, kita menehi foto.
Apa sing istimewa? - Bentenipun gedhe antarane lalu lintas mlebu lan metu. Lalu lintas mlebu sithik banget, lalu lintas metu akeh banget:
Yen sampeyan ndeleng grafik kasebut, sampeyan bisa ndeleng manawa direktur nampa udakara 200 MB per detik, iki dina sing biasa. Kita menehi bali 4,500 MB per detik, rasio kita kira-kira 1/22. Wis jelas yen kanggo nyedhiyakake lalu lintas metu kanthi lengkap menyang 22 server buruh, kita mung butuh siji sing nampa sambungan iki. Iki ngendi algoritma nuntun langsung teka kanggo bantuan kita.
Apa sing katon? Direktur foto kita, miturut mejane, ngirim sambungan menyang router foto. Nanging router foto ngirim bali lalu lintas langsung menyang Internet, ngirim menyang klien, iku ora bali liwat direktur foto, mangkono, karo nomer minimal mesin, kita njamin toleransi fault lengkap lan pumping kabeh lalu lintas. Ing configs katon kaya iki: kita nemtokake algoritma, ing kasus kita iku rr prasaja, nyedhiyani cara nuntun langsung lan banjur wiwiti dhaptar kabeh server nyata, carane akeh sing kita duwe. Sing bakal nemtokake lalu lintas iki. Yen ana siji utawa loro server liyane, utawa sawetara server, ana kabutuhan - kita mung nambah bagean iki menyang konfigurasi lan aja kuwatir banget. Saka sisih server nyata, saka sisih router foto, cara iki mbutuhake konfigurasi paling tithik, diterangake kanthi sampurna ing dokumentasi, lan ora ana pitfalls.
Sing paling apik yaiku solusi kasebut ora nggambarake desain ulang jaringan lokal sing radikal; iki penting kanggo kita; kita kudu ngrampungake iki kanthi biaya minimal. Yen sampeyan ndeleng , banjur kita bakal weruh kaya apa. Kene kita duwe server virtual tartamtu, ing port 443, ngrungokake, nampa sambungan, kabeh server apa wis kadhaptar, lan sampeyan bisa ndeleng sing sambungan, menehi utawa njupuk, padha. Yen kita ndeleng statistik ing server virtual sing padha, kita duwe paket mlebu, sambungan mlebu, nanging pancen ora ana sing metu. Sambungan metu langsung menyang klien. Oke, kita bisa unbalance. Saiki, apa sing kedadeyan yen salah sawijining router foto gagal? Sawise kabeh, wesi iku wesi. Bisa dadi panik kernel, bisa rusak, sumber daya bisa kobong. opo wae. Pramila priksa kesehatan dibutuhake. Padha bisa dadi prasaja minangka mriksa carane port mbukak, utawa soko liyane Komplek, nganti sawetara Tulisan ngarep-ditulis malah bakal mriksa logika bisnis.
Kita mandheg nang endi wae ing tengah: kita duwe panjalukan https menyang lokasi tartamtu, skrip kasebut diarani, yen nanggapi kanthi respon kaping 200, kita percaya yen kabeh apik karo server iki, sing urip lan bisa diuripake. gampang.
Carane iki, maneh, katon ing laku? Ayo mateni server kanggo pangopènan - sumunar BIOS, contone. Ing log, kita langsung duwe wektu entek, kita ndeleng baris pisanan, banjur sawise telung usaha ditandhani minangka "gagal", lan mung dibusak saka dhaftar.
A opsi prilaku liya uga bisa, nalika VS mung disetel kanggo nul, nanging yen foto bali, iki ora bisa uga. Server muncul, Nginx diwiwiti, priksa kesehatan langsung ngerti manawa sambungan kasebut bisa digunakake, kabeh apik, lan server katon ing dhaptar kita, lan beban kasebut langsung ditrapake. Ora ana tumindak manual sing dibutuhake saka administrator tugas. Server reboot ing wayah wengi - departemen ngawasi ora nelpon kita babagan iki ing wayah wengi. Dheweke ngandhani yen kedadeyan kasebut, kabeh apik.
Dadi, kanthi cara sing cukup prasaja, kanthi bantuan sawetara server, kita ngrampungake masalah toleransi kesalahan eksternal.
Kabeh sing kudu dicritakake yaiku kabeh iki, mesthi, kudu dipantau. Kapisah, kudu dicathet yen Keepalivede, minangka piranti lunak sing wis suwe ditulis, duwe akeh cara kanggo ngawasi, loro-lorone nggunakake mriksa liwat DBus, SMTP, SNMP, lan Zabbix standar. Kajaba iku, dheweke dhewe ngerti carane nulis layang kanggo meh saben wahing, lan jujur, ing sawetara titik, kita malah mikir kanggo mateni, amarga dheweke nulis akeh huruf kanggo owah-owahan lalu lintas, ngalih, kanggo saben sambungan IP, lan sapanunggalane . Mesthine, yen ana akeh server, mula sampeyan bisa ngatasi huruf kasebut. Kita ngawasi nginx ing router foto nggunakake metode standar, lan ngawasi hardware durung ilang. Mesthi wae, kita bakal menehi saran rong perkara liyane: sepisanan, mriksa kesehatan eksternal lan kasedhiyan, amarga sanajan kabeh bisa digunakake, bisa uga pangguna ora nampa foto amarga ana masalah karo panyedhiya eksternal utawa sing luwih rumit. Iku tansah worth tetep nang endi wae ing jaringan liyane, ing Amazon utawa nang endi wae liya, mesin kapisah sing bisa ping server saka njaba, lan iku uga worth nggunakake salah siji deteksi anomali, kanggo sing ngerti carane nindakake machine learning angel, utawa ngawasi prasaja, paling supaya kanggo trek yen panjalukan wis dropped banget, utawa, ing nalisir, tambah. Uga bisa migunani.
Ayo ngringkes: kita, nyatane, ngganti solusi sing nganggo wesi, sing ing sawetara titik ora cocog karo kita, kanthi sistem sing cukup prasaja sing nindakake kabeh sing padha, yaiku, nyedhiyakake penghentian lalu lintas HTTPS lan nuntun luwih pinter karo priksa kesehatan sing perlu. Kita wis nambah stabilitas sistem iki, yaiku, kita isih duwe kasedhiyan dhuwur kanggo saben lapisan, plus kita duwe bonus sing cukup gampang kanggo ukuran kabeh ing saben lapisan, amarga hardware standar karo piranti lunak standar, yaiku. , kita wis simplified diagnosa masalah bisa.
Apa kita mungkasi? Kita duwe masalah nalika preian Januari 2018. Ing enem sasi kapisan nalika kita sijine rencana iki menyang operasi, kita ditambahi kanggo kabeh lalu lintas kanggo mbusak kabeh lalu lintas saka LTM, kita tansaya mung ing lalu lintas ing siji pusat data saka 40 gigabit kanggo 60 gigabits, lan ing wektu sing padha kanggo kabeh 2018 taun bisa ngirim meh kaping telu liyane foto saben detik.
Source: www.habr.com