Badoo એ કેવી રીતે પ્રતિ સેકન્ડ 200k ફોટા મોકલવાની ક્ષમતા હાંસલ કરી

આધુનિક વેબ મીડિયા સામગ્રી વિના લગભગ અકલ્પ્ય છે: લગભગ દરેક દાદી પાસે સ્માર્ટફોન છે, દરેક સોશિયલ નેટવર્ક પર છે, અને જાળવણીમાં ડાઉનટાઇમ કંપનીઓ માટે ખર્ચાળ છે. અહીં કંપનીની વાર્તાની ટ્રાન્સક્રિપ્ટ છે Badoo તેણીએ હાર્ડવેર સોલ્યુશનનો ઉપયોગ કરીને ફોટાની ડિલિવરી કેવી રીતે ગોઠવી, પ્રક્રિયામાં તેણીને કઈ કામગીરીની સમસ્યાઓ આવી, તેનું કારણ શું છે અને તમામ સ્તરે ખામી સહિષ્ણુતા સુનિશ્ચિત કરતી વખતે, Nginx પર આધારિત સોફ્ટવેર સોલ્યુશનનો ઉપયોગ કરીને આ સમસ્યાઓ કેવી રીતે હલ કરવામાં આવી તે વિશે (видео). અમે ઓલેગની વાર્તાના લેખકોનો આભાર માનીએ છીએ સાનિસ એફિમોવા અને એલેક્ઝાન્ડ્રા ડાયમોવા, જેમણે કોન્ફરન્સમાં તેમનો અનુભવ શેર કર્યો હતો અપટાઇમ દિવસ 4.

- ચાલો આપણે ફોટા કેવી રીતે સંગ્રહિત અને કેશ કરીએ તે વિશે થોડી પરિચય સાથે શરૂઆત કરીએ. અમારી પાસે એક સ્તર છે જ્યાં અમે તેમને સંગ્રહિત કરીએ છીએ, અને એક સ્તર જ્યાં અમે ફોટાને કેશ કરીએ છીએ. તે જ સમયે, જો આપણે ઉચ્ચ યુક્તિ દર હાંસલ કરવા અને સ્ટોરેજ પરનો ભાર ઘટાડવા માંગીએ છીએ, તો તે અમારા માટે મહત્વપૂર્ણ છે કે વ્યક્તિગત વપરાશકર્તાનો દરેક ફોટો એક કેશીંગ સર્વર પર હોય. નહિંતર, આપણી પાસે જેટલા સર્વર છે તેટલી ગણી વધુ ડિસ્ક ઇન્સ્ટોલ કરવી પડશે. અમારો યુક્તિ દર લગભગ 99% છે, એટલે કે, અમે અમારા સ્ટોરેજ પરનો ભાર 100 ગણો ઘટાડી રહ્યા છીએ, અને આ કરવા માટે, 10 વર્ષ પહેલાં, જ્યારે આ બધું બનાવવામાં આવી રહ્યું હતું, ત્યારે અમારી પાસે 50 સર્વર હતા. તદનુસાર, આ ફોટા સર્વ કરવા માટે, અમને આવશ્યકપણે 50 બાહ્ય ડોમેન્સની જરૂર છે જે આ સર્વર્સ સેવા આપે છે.

સ્વાભાવિક રીતે, તરત જ પ્રશ્ન ઊભો થયો: જો આપણું એક સર્વર ડાઉન થઈ જાય અને અનુપલબ્ધ થઈ જાય, તો આપણે ટ્રાફિકનો કયો ભાગ ગુમાવીએ છીએ? અમે બજારમાં શું હતું તે જોયું અને હાર્ડવેરનો ટુકડો ખરીદવાનું નક્કી કર્યું જેથી તે અમારી બધી સમસ્યાઓનું નિરાકરણ લાવે. પસંદગી F5-નેટવર્ક કંપનીના ઉકેલ પર પડી (જે માર્ગ દ્વારા, તાજેતરમાં NGINX, Inc ખરીદ્યું છે): BIG-IP સ્થાનિક ટ્રાફિક મેનેજર.

હાર્ડવેરનો આ ભાગ (LTM) શું કરે છે: તે એક આયર્ન રાઉટર છે જે તેના બાહ્ય બંદરોની આયર્ન રીડન્ડન્સી બનાવે છે અને તમને નેટવર્ક ટોપોલોજીના આધારે, કેટલીક સેટિંગ્સ પર, અને આરોગ્ય તપાસ કરવા માટે તમને ટ્રાફિકને રૂટ કરવાની મંજૂરી આપે છે. અમારા માટે તે મહત્વનું હતું કે હાર્ડવેરનો આ ભાગ પ્રોગ્રામ કરી શકાય. તદનુસાર, અમે ચોક્કસ કેશમાંથી ચોક્કસ વપરાશકર્તાના ફોટોગ્રાફ્સ કેવી રીતે પીરસવામાં આવ્યા હતા તેના તર્કનું વર્ણન કરી શકીએ છીએ. શાના જેવું લાગે છે? હાર્ડવેરનો એક ભાગ છે જે એક ડોમેન, એક IP પર ઈન્ટરનેટને જુએ છે, ssl offload કરે છે, HTTP વિનંતીઓને પાર્સ કરે છે, IRuleમાંથી કેશ નંબર પસંદ કરે છે, ક્યાં જવું છે અને ટ્રાફિકને ત્યાં જવા દે છે. તે જ સમયે, તે સ્વાસ્થ્ય તપાસ કરે છે, અને કેટલાક મશીન અનુપલબ્ધ હોવાના કિસ્સામાં, તે સમયે અમે તેને બનાવ્યું હતું જેથી ટ્રાફિક એક બેકઅપ સર્વર પર જાય. રૂપરેખાંકનના દૃષ્ટિકોણથી, ત્યાં, અલબત્ત, કેટલીક ઘોંઘાટ છે, પરંતુ સામાન્ય રીતે બધું એકદમ સરળ છે: અમે કાર્ડ રજીસ્ટર કરીએ છીએ, નેટવર્ક પર અમારા IP પર ચોક્કસ નંબરનો પત્રવ્યવહાર, અમે કહીએ છીએ કે અમે પોર્ટ્સ 80 પર સાંભળીશું. અને 443, અમે કહીએ છીએ કે જો સર્વર અનુપલબ્ધ હોય, તો તમારે ટ્રાફિકને બેકઅપ પર મોકલવાની જરૂર છે, આ કિસ્સામાં 35મી, અને અમે આ આર્કિટેક્ચરને કેવી રીતે ડિસએસેમ્બલ કરવું જોઈએ તેના પર તર્કના સમૂહનું વર્ણન કરીએ છીએ. એકમાત્ર સમસ્યા એ હતી કે જે ભાષામાં હાર્ડવેર પ્રોગ્રામ કરવામાં આવ્યું હતું તે Tcl હતી. જો કોઈને આ બિલકુલ યાદ હોય તો... આ ભાષા પ્રોગ્રામિંગ માટે અનુકૂળ ભાષા કરતાં માત્ર લખવા માટે વધુ છે:

અમને શું મળ્યું? અમને હાર્ડવેરનો એક ભાગ મળ્યો છે જે અમારા ઈન્ફ્રાસ્ટ્રક્ચરની ઉચ્ચ ઉપલબ્ધતાની ખાતરી કરે છે, અમારા તમામ ટ્રાફિકને રૂટ કરે છે, સ્વાસ્થ્ય લાભો પ્રદાન કરે છે અને યોગ્ય કાર્ય કરે છે. તદુપરાંત, તે લાંબા સમયથી કામ કરે છે: છેલ્લા 10 વર્ષોમાં તેના વિશે કોઈ ફરિયાદ નથી. 2018 ની શરૂઆતમાં, અમે પહેલાથી જ પ્રતિ સેકન્ડ લગભગ 80k ફોટા મોકલી રહ્યા હતા. આ ક્યાંક અમારા બંને ડેટા કેન્દ્રોમાંથી લગભગ 80 ગીગાબિટ ટ્રાફિક છે.

જોકે…

2018 ની શરૂઆતમાં, અમે ચાર્ટ પર એક કદરૂપું ચિત્ર જોયું: ફોટા મોકલવામાં જે સમય લાગ્યો તે સ્પષ્ટપણે વધી ગયો હતો. અને તે અમને અનુકૂળ કરવાનું બંધ કરી દીધું. સમસ્યા એ છે કે આ વર્તન ફક્ત ટ્રાફિકના શિખર દરમિયાન જ દેખાતું હતું - અમારી કંપની માટે આ રવિવારથી સોમવારની રાત છે. પરંતુ બાકીના સમયે સિસ્ટમ રાબેતા મુજબ વર્તી રહી હતી, નિષ્ફળતાના કોઈ ચિહ્નો નથી.

તેમ છતાં, સમસ્યા હલ કરવાની હતી. અમે સંભવિત અવરોધોને ઓળખી કાઢ્યા અને તેને દૂર કરવાનું શરૂ કર્યું. સૌ પ્રથમ, અલબત્ત, અમે બાહ્ય અપલિંકનો વિસ્તાર કર્યો, આંતરિક અપલિંકનું સંપૂર્ણ ઓડિટ કર્યું અને તમામ સંભવિત અવરોધો શોધી કાઢ્યા. પરંતુ આ બધાએ સ્પષ્ટ પરિણામ આપ્યું નથી, સમસ્યા અદૃશ્ય થઈ નથી.

અન્ય સંભવિત અડચણ એ ફોટો કેશનું પ્રદર્શન હતું. અને અમે નક્કી કર્યું કે કદાચ સમસ્યા તેમની સાથે છે. ઠીક છે, અમે પ્રદર્શનને વિસ્તૃત કર્યું છે - મુખ્યત્વે ફોટો કેશ પર નેટવર્ક પોર્ટ્સ. પરંતુ ફરીથી કોઈ સ્પષ્ટ સુધારો જોવા મળ્યો ન હતો. અંતે, અમે એલટીએમના જ પ્રદર્શન પર ખૂબ ધ્યાન આપ્યું, અને અહીં અમે ગ્રાફ પર એક ઉદાસી ચિત્ર જોયું: બધા સીપીયુ પરનો ભાર સરળતાથી જવાનું શરૂ કરે છે, પરંતુ પછી અચાનક એક ઉચ્ચપ્રદેશ પર આવે છે. તે જ સમયે, એલટીએમ આરોગ્ય તપાસો અને અપલિંક્સને પર્યાપ્ત રીતે પ્રતિસાદ આપવાનું બંધ કરે છે અને તેમને રેન્ડમલી બંધ કરવાનું શરૂ કરે છે, જે ગંભીર કામગીરીમાં ઘટાડો તરફ દોરી જાય છે.

એટલે કે, અમે સમસ્યાના સ્ત્રોતને ઓળખી કાઢ્યા છે, અડચણને ઓળખી છે. આપણે શું કરીશું તે નક્કી કરવાનું બાકી છે.

પ્રથમ, સૌથી સ્પષ્ટ વસ્તુ જે આપણે કરી શકીએ તે એ છે કે કોઈક રીતે LTMને જ આધુનિક બનાવવું. પરંતુ અહીં કેટલીક ઘોંઘાટ છે, કારણ કે આ હાર્ડવેર એકદમ અનોખું છે, તમે નજીકના સુપરમાર્કેટમાં જઈને તેને ખરીદશો નહીં. આ એક અલગ કરાર છે, એક અલગ લાઇસન્સ કરાર છે, અને તે ઘણો સમય લેશે. બીજો વિકલ્પ એ છે કે તમારા માટે વિચારવાનું શરૂ કરો, તમારા પોતાના ઘટકોનો ઉપયોગ કરીને તમારા પોતાના ઉકેલ સાથે આવો, પ્રાધાન્ય ઓપન એક્સેસ પ્રોગ્રામનો ઉપયોગ કરીને. જે બાકી છે તે નક્કી કરવાનું છે કે આપણે આ માટે બરાબર શું પસંદ કરીશું અને આ સમસ્યાને ઉકેલવા માટે કેટલો સમય ફાળવીશું, કારણ કે વપરાશકર્તાઓને પૂરતા ફોટા મળ્યા નથી. તેથી, આપણે આ બધું ખૂબ જ ઝડપથી કરવાની જરૂર છે, કોઈ ગઈકાલે કહી શકે છે.

કારણ કે કાર્ય "શક્ય તેટલું ઝડપથી કંઈક કરો અને અમારી પાસે જે હાર્ડવેર છે તેનો ઉપયોગ કરો" જેવો સંભળાઈ રહ્યો હતો, કારણ કે આપણે સૌ પ્રથમ વિચાર્યું કે આગળના કેટલાક ખૂબ શક્તિશાળી મશીનોને ખાલી દૂર કરવા, ત્યાં Nginx મૂકો, જેની સાથે આપણે જાણીએ છીએ કે કેવી રીતે કરવું. કામ કરો અને હાર્ડવેર કરતા હતા તે જ તર્કને અમલમાં મૂકવાનો પ્રયાસ કરો. એટલે કે, વાસ્તવમાં, અમે અમારું હાર્ડવેર છોડી દીધું, 4 વધુ સર્વર્સ ઇન્સ્ટોલ કર્યા જે અમારે રૂપરેખાંકિત કરવાના હતા, તેમના માટે બાહ્ય ડોમેન્સ બનાવ્યા, જેમ કે તે 10 વર્ષ પહેલાં હતું... જો આ મશીનો પડી ગયા તો અમે ઉપલબ્ધતામાં થોડું ગુમાવ્યું, પરંતુ હજુ પણ ઓછું, તેઓએ સ્થાનિક રીતે અમારા વપરાશકર્તાઓની સમસ્યા હલ કરી.

તદનુસાર, તર્ક સમાન રહે છે: અમે Nginx ઇન્સ્ટોલ કરીએ છીએ, તે SSL-ઓફલોડ કરી શકે છે, અમે કોઈક રીતે રૂટીંગ લોજીકને પ્રોગ્રામ કરી શકીએ છીએ, રૂપરેખાઓમાં આરોગ્ય-તપાસ કરી શકીએ છીએ અને અમારી પાસે પહેલા હતા તે તર્કની નકલ કરી શકીએ છીએ.

ચાલો રૂપરેખાઓ લખવા બેસીએ. શરૂઆતમાં એવું લાગતું હતું કે બધું ખૂબ જ સરળ હતું, પરંતુ, કમનસીબે, દરેક કાર્ય માટે મેન્યુઅલ શોધવાનું ખૂબ મુશ્કેલ છે. તેથી, અમે ફક્ત "ફોટા માટે Nginx કેવી રીતે ગોઠવવું" ગૂગલિંગ કરવાની ભલામણ કરતા નથી: સત્તાવાર દસ્તાવેજોનો સંદર્ભ લેવાનું વધુ સારું છે, જે બતાવશે કે કઈ સેટિંગ્સને સ્પર્શ કરવી જોઈએ. પરંતુ ચોક્કસ પરિમાણ જાતે પસંદ કરવાનું વધુ સારું છે. ઠીક છે, તો પછી બધું સરળ છે: અમે અમારી પાસેના સર્વર્સનું વર્ણન કરીએ છીએ, અમે પ્રમાણપત્રોનું વર્ણન કરીએ છીએ... પરંતુ સૌથી રસપ્રદ બાબત એ છે કે, હકીકતમાં, રૂટીંગ લોજિક પોતે જ છે.

શરૂઆતમાં અમને એવું લાગતું હતું કે અમે ફક્ત અમારા સ્થાનનું વર્ણન કરી રહ્યા છીએ, તેમાં અમારા ફોટો કેશની સંખ્યા સાથે મેચ કરી રહ્યા છીએ, અમને કેટલા અપસ્ટ્રીમ્સની જરૂર છે તે વર્ણવવા માટે અમારા હાથ અથવા જનરેટરનો ઉપયોગ કરી રહ્યા છીએ, દરેક અપસ્ટ્રીમમાં અમે સર્વર સૂચવે છે કે જેના પર ટ્રાફિક હોવો જોઈએ. જાઓ, અને બેકઅપ સર્વર - જો મુખ્ય સર્વર ઉપલબ્ધ ન હોય તો:

પરંતુ, કદાચ, જો બધું ખૂબ સરળ હોત, તો અમે ફક્ત ઘરે જઈશું અને કંઈપણ કહીશું નહીં. કમનસીબે, ડિફૉલ્ટ Nginx સેટિંગ્સ સાથે, જે, સામાન્ય રીતે, વિકાસના ઘણા વર્ષોમાં બનાવવામાં આવી હતી અને આ કેસ માટે સંપૂર્ણપણે યોગ્ય નથી... રૂપરેખા આના જેવી દેખાય છે: જો કેટલાક અપસ્ટ્રીમ સર્વરમાં વિનંતી ભૂલ અથવા સમય સમાપ્ત થાય, તો Nginx હંમેશા ટ્રાફિકને આગલા પર સ્વિચ કરે છે. તદુપરાંત, પ્રથમ નિષ્ફળતા પછી, 10 સેકંડમાં સર્વર પણ બંધ થઈ જશે, ભૂલથી અને સમયસમાપ્તિ બંને - આ કોઈપણ રીતે ગોઠવી શકાતું નથી. એટલે કે, જો આપણે અપસ્ટ્રીમ ડાયરેક્ટિવમાં સમયસમાપ્તિ વિકલ્પને દૂર અથવા રીસેટ કરીએ છીએ, તો પછી, Nginx આ વિનંતી પર પ્રક્રિયા કરશે નહીં અને કેટલીક ખૂબ સારી ભૂલ સાથે પ્રતિસાદ આપશે નહીં, તો સર્વર બંધ થઈ જશે.

આને અવગણવા માટે, અમે બે વસ્તુઓ કરી:

a) તેઓએ Nginx ને આ મેન્યુઅલી કરવાથી મનાઈ ફરમાવી હતી - અને કમનસીબે, આ કરવાનો એકમાત્ર રસ્તો એ છે કે મહત્તમ નિષ્ફળ સેટિંગ્સ સેટ કરવી.

b) અમને યાદ છે કે અન્ય પ્રોજેક્ટ્સમાં અમે એક મોડ્યુલનો ઉપયોગ કરીએ છીએ જે અમને પૃષ્ઠભૂમિ આરોગ્ય તપાસો કરવાની મંજૂરી આપે છે - તે મુજબ, અમે વારંવાર આરોગ્ય તપાસો કરી હતી જેથી અકસ્માતની ઘટનામાં ડાઉનટાઇમ ન્યૂનતમ હોય.

કમનસીબે, આ બધુ જ નથી, કારણ કે શાબ્દિક રીતે આ યોજનાની કામગીરીના પ્રથમ બે અઠવાડિયાએ દર્શાવ્યું હતું કે TCP આરોગ્ય-તપાસ પણ એક અવિશ્વસનીય બાબત છે: અપસ્ટ્રીમ સર્વર પર તે Nginx અથવા D-રાજ્યમાં Nginx ન હોઈ શકે, અને આ કિસ્સામાં કર્નલ કનેક્શન સ્વીકારશે, હેલ્થ-ચેક પસાર થશે, પરંતુ કામ કરશે નહીં. તેથી, અમે તરત જ આને હેલ્થ-ચેક HTTP સાથે બદલ્યું, એક ચોક્કસ બનાવ્યું, જે, જો તે 200 પરત કરે છે, તો બધું આ સ્ક્રિપ્ટમાં કાર્ય કરે છે. તમે વધારાના તર્ક કરી શકો છો - ઉદાહરણ તરીકે, સર્વર્સ કેશીંગના કિસ્સામાં, તપાસો કે ફાઇલ સિસ્ટમ યોગ્ય રીતે માઉન્ટ થયેલ છે:

અને આ અમને અનુકૂળ કરશે, સિવાય કે આ ક્ષણે સર્કિટ હાર્ડવેરએ જે કર્યું તે સંપૂર્ણપણે પુનરાવર્તિત કર્યું. પરંતુ અમે વધુ સારું કરવા માગતા હતા. પહેલાં, અમારી પાસે એક બેકઅપ સર્વર હતું, અને આ કદાચ બહુ સારું નથી, કારણ કે જો તમારી પાસે સો સર્વર હોય, તો પછી જ્યારે એક સાથે ઘણા નિષ્ફળ જાય, ત્યારે એક બેકઅપ સર્વર લોડનો સામનો કરી શકે તેવી શક્યતા નથી. તેથી, અમે તમામ સર્વર પર આરક્ષણનું વિતરણ કરવાનું નક્કી કર્યું: અમે ખાલી અન્ય અલગ અપસ્ટ્રીમ બનાવ્યું, ત્યાંના તમામ સર્વર્સને તેઓ સેવા આપી શકે તેવા લોડને અનુરૂપ ચોક્કસ પરિમાણો સાથે લખ્યા, અમારી પાસે પહેલા જે આરોગ્ય તપાસ હતી તે જ ઉમેર્યા:

એક અપસ્ટ્રીમમાં બીજા અપસ્ટ્રીમ પર જવું અશક્ય હોવાથી, એ સુનિશ્ચિત કરવું જરૂરી હતું કે જો મુખ્ય અપસ્ટ્રીમ, જેમાં અમે ફક્ત સાચો, જરૂરી ફોટો કેશ રેકોર્ડ કર્યો છે, તે અનુપલબ્ધ હોય, તો અમે ફૉલબેક કરવા માટે ખાલી error_pageમાંથી પસાર થયા હતા. જ્યાં અમે બેકઅપ અપસ્ટ્રીમ પર ગયા:

અને શાબ્દિક રીતે ચાર સર્વર્સ ઉમેરીને, અમને આ મળ્યું: અમે લોડનો એક ભાગ બદલ્યો - અમે તેને LTM માંથી આ સર્વર્સ પર દૂર કર્યો, ત્યાં સમાન તર્ક લાગુ કર્યો, પ્રમાણભૂત હાર્ડવેર અને સૉફ્ટવેરનો ઉપયોગ કરીને, અને તરત જ બોનસ પ્રાપ્ત કર્યું જે આ સર્વર્સ કરી શકે છે. માપવામાં આવે છે, કારણ કે તે ફક્ત જરૂરી હોય તેટલું સપ્લાય કરી શકાય છે. ઠીક છે, એકમાત્ર નકારાત્મક એ છે કે અમે બાહ્ય વપરાશકર્તાઓ માટે ઉચ્ચ ઉપલબ્ધતા ગુમાવી દીધી છે. પરંતુ તે ક્ષણે અમારે આ બલિદાન આપવું પડ્યું, કારણ કે તે તાત્કાલિક સમસ્યાનું નિરાકરણ જરૂરી હતું. તેથી, અમે લોડનો એક ભાગ દૂર કર્યો, તે સમયે તે લગભગ 40% હતો, LTM સારું લાગ્યું, અને શાબ્દિક રીતે સમસ્યા શરૂ થયાના બે અઠવાડિયા પછી, અમે પ્રતિ સેકન્ડ 45k વિનંતીઓ નહીં, પરંતુ 55k મોકલવાનું શરૂ કર્યું. હકીકતમાં, અમે 20% વધ્યા - આ સ્પષ્ટપણે ટ્રાફિક છે જે અમે વપરાશકર્તાને આપ્યો નથી. અને તે પછી તેઓએ બાકીની સમસ્યાને કેવી રીતે હલ કરવી તે વિશે વિચારવાનું શરૂ કર્યું - ઉચ્ચ બાહ્ય સુલભતા સુનિશ્ચિત કરવા.

અમારી પાસે થોડો વિરામ હતો, જે દરમિયાન અમે આ માટે કયા ઉપાયનો ઉપયોગ કરીશું તેની ચર્ચા કરી. DNS નો ઉપયોગ કરીને વિશ્વસનીયતા સુનિશ્ચિત કરવા માટે દરખાસ્તો કરવામાં આવી હતી, કેટલીક હોમ-લિખિત સ્ક્રિપ્ટો, ડાયનેમિક રૂટીંગ પ્રોટોકોલની મદદથી... ત્યાં ઘણા બધા વિકલ્પો હતા, પરંતુ તે પહેલાથી જ સ્પષ્ટ થઈ ગયું છે કે ફોટાની ખરેખર વિશ્વસનીય ડિલિવરી માટે, તમારે બીજું સ્તર રજૂ કરવાની જરૂર છે જે આની દેખરેખ રાખશે. અમે આ મશીનોને ફોટો ડિરેક્ટર તરીકે ઓળખાવ્યા. અમે જે સોફ્ટવેર પર આધાર રાખતા હતા તે Keepalived હતું:

શરૂઆતમાં, Keepalived શું સમાવે છે? પહેલો VRRP પ્રોટોકોલ છે, જે નેટવર્કર્સ માટે વ્યાપકપણે જાણીતો છે, જે નેટવર્ક સાધનો પર સ્થિત છે જે ક્લાયન્ટ્સ કનેક્ટ કરે છે તે બાહ્ય IP સરનામાંને દોષ સહિષ્ણુતા પ્રદાન કરે છે. બીજો ભાગ IPVS, IP વર્ચ્યુઅલ સર્વર છે, ફોટો રાઉટર્સ વચ્ચે સંતુલન અને આ સ્તરે ખામી સહિષ્ણુતા સુનિશ્ચિત કરવા માટે. અને ત્રીજું - આરોગ્ય તપાસો.

ચાલો પહેલા ભાગથી શરૂઆત કરીએ: VRRP - તે કેવો દેખાય છે? ત્યાં ચોક્કસ વર્ચ્યુઅલ IP છે, જે dns badoocdn.com માં એન્ટ્રી ધરાવે છે, જ્યાં ક્લાયન્ટ કનેક્ટ થાય છે. અમુક સમયે, અમારી પાસે એક સર્વર પર IP સરનામું હોય છે. VRRP પ્રોટોકોલનો ઉપયોગ કરીને સર્વર વચ્ચે કીપલાઈવ્ડ પેકેટો ચાલે છે, અને જો માસ્ટર રડારમાંથી અદૃશ્ય થઈ જાય - સર્વર રીબૂટ થઈ ગયું હોય અથવા બીજું કંઈક હોય, તો બેકઅપ સર્વર આપમેળે આ IP સરનામું પસંદ કરે છે - કોઈ મેન્યુઅલ ક્રિયાઓની જરૂર નથી. માસ્ટર અને બેકઅપ વચ્ચેનો તફાવત મુખ્યત્વે પ્રાથમિકતા છે: તે જેટલું ઊંચું છે, મશીન માસ્ટર બનવાની તકો વધારે છે. એક ખૂબ જ મોટો ફાયદો એ છે કે તમારે સર્વર પર જ IP સરનામાંને ગોઠવવાની જરૂર નથી, તે તેમને રૂપરેખામાં વર્ણવવા માટે પૂરતું છે, અને જો IP સરનામાંઓને કેટલાક કસ્ટમ રૂટીંગ નિયમોની જરૂર હોય, તો તે સીધા જ રૂપરેખામાં વર્ણવેલ છે. VRRP પેકેજમાં વર્ણવ્યા પ્રમાણે સમાન વાક્યરચના. તમે કોઈ અજાણી વસ્તુઓનો સામનો કરશો નહીં.

વ્યવહારમાં આ શું દેખાય છે? જો સર્વરમાંથી એક નિષ્ફળ જાય તો શું થશે? જલદી માસ્ટર અદૃશ્ય થઈ જાય છે, અમારું બેકઅપ જાહેરાતો પ્રાપ્ત કરવાનું બંધ કરે છે અને આપમેળે માસ્ટર બની જાય છે. થોડા સમય પછી, અમે માસ્ટરનું સમારકામ કર્યું, રીબૂટ કર્યું, Keepalived ઊભું કર્યું - જાહેરાતો બેકઅપ કરતાં વધુ પ્રાધાન્યતા સાથે આવે છે, અને બેકઅપ આપમેળે પાછું વળે છે, IP સરનામાઓ દૂર કરે છે, કોઈ મેન્યુઅલ ક્રિયાઓ કરવાની જરૂર નથી.

આમ, અમે બાહ્ય IP એડ્રેસની ખામી સહિષ્ણુતા સુનિશ્ચિત કરી છે. આગળનો ભાગ કોઈક રીતે બાહ્ય IP સરનામાંથી ફોટો રાઉટર્સ સુધીના ટ્રાફિકને સંતુલિત કરવાનો છે જે તેને પહેલાથી જ સમાપ્ત કરી રહ્યાં છે. સંતુલન પ્રોટોકોલ સાથે બધું એકદમ સ્પષ્ટ છે. આ કાં તો એક સરળ રાઉન્ડ-રોબિન છે, અથવા થોડી વધુ જટિલ વસ્તુઓ, wrr, લિસ્ટ કનેક્શન અને તેથી વધુ. આ મૂળભૂત રીતે દસ્તાવેજીકરણમાં વર્ણવેલ છે, ત્યાં ખાસ કંઈ નથી. પરંતુ ડિલિવરી પદ્ધતિ... અહીં અમે તેમાંથી એક શા માટે પસંદ કર્યું છે તેના પર નજીકથી નજર નાખીશું. આ NAT, ડાયરેક્ટ રૂટીંગ અને TUN છે. હકીકત એ છે કે અમે તરત જ સાઇટ્સ પરથી 100 ગીગાબિટ ટ્રાફિક પહોંચાડવાનું આયોજન કર્યું છે. જો તમે અંદાજ લગાવો છો, તો તમારે 10 ગીગાબીટ કાર્ડની જરૂર છે, ખરું ને? એક સર્વરમાં 10 ગીગાબીટ કાર્ડ્સ પહેલાથી જ અમારા "માનક સાધનો" ના ખ્યાલના અવકાશની બહાર છે. અને પછી અમને યાદ આવ્યું કે અમે ફક્ત થોડો ટ્રાફિક આપતા નથી, અમે ફોટા આપીએ છીએ.

શું ખાસ છે? - ઇનકમિંગ અને આઉટગોઇંગ ટ્રાફિક વચ્ચે મોટો તફાવત. ઇનકમિંગ ટ્રાફિક ખૂબ નાનો છે, આઉટગોઇંગ ટ્રાફિક ખૂબ મોટો છે:

જો તમે આ ગ્રાફ્સ જુઓ છો, તો તમે જોઈ શકો છો કે આ ક્ષણે ડિરેક્ટર લગભગ 200 MB પ્રતિ સેકન્ડ મેળવે છે, આ ખૂબ જ સામાન્ય દિવસ છે. અમે પ્રતિ સેકન્ડ 4,500 MB પાછા આપીએ છીએ, અમારો ગુણોત્તર આશરે 1/22 છે. તે પહેલેથી જ સ્પષ્ટ છે કે 22 વર્કર સર્વર્સને સંપૂર્ણ રીતે આઉટગોઇંગ ટ્રાફિક પ્રદાન કરવા માટે, અમને ફક્ત એકની જરૂર છે જે આ કનેક્શન સ્વીકારે. આ તે છે જ્યાં ડાયરેક્ટ રૂટીંગ અલ્ગોરિધમ અમારી સહાય માટે આવે છે.

શાના જેવું લાગે છે? અમારા ફોટો ડિરેક્ટર, તેમના ટેબલ અનુસાર, ફોટો રાઉટર્સમાં કનેક્શન્સ ટ્રાન્સમિટ કરે છે. પરંતુ ફોટો રાઉટર્સ રીટર્ન ટ્રાફિકને સીધો ઈન્ટરનેટ પર મોકલે છે, તેને ક્લાયન્ટને મોકલે છે, તે ફોટો ડાયરેક્ટર દ્વારા પાછો જતો નથી, આમ, ઓછામાં ઓછી સંખ્યામાં મશીનો સાથે, અમે સંપૂર્ણ ખામી સહિષ્ણુતા અને તમામ ટ્રાફિકના પમ્પિંગની ખાતરી કરીએ છીએ. રૂપરેખાઓમાં તે આના જેવું દેખાય છે: અમે અલ્ગોરિધમનો ઉલ્લેખ કરીએ છીએ, અમારા કિસ્સામાં તે એક સરળ આરઆર છે, સીધી રૂટીંગ પદ્ધતિ પ્રદાન કરો અને પછી બધા વાસ્તવિક સર્વર્સની સૂચિ બનાવવાનું શરૂ કરો, તેમાંથી કેટલા અમારી પાસે છે. જે આ ટ્રાફિક નક્કી કરશે. જો આપણી પાસે ત્યાં એક અથવા બે વધુ સર્વર્સ હોય, અથવા ઘણા સર્વર્સ હોય, તો આવી જરૂરિયાત ઊભી થાય છે - અમે ફક્ત આ વિભાગને રૂપરેખામાં ઉમેરીએ છીએ અને વધુ ચિંતા કરશો નહીં. વાસ્તવિક સર્વર્સની બાજુથી, ફોટો રાઉટરની બાજુથી, આ પદ્ધતિને સૌથી ન્યૂનતમ ગોઠવણીની જરૂર છે, તે દસ્તાવેજીકરણમાં સંપૂર્ણ રીતે વર્ણવેલ છે, અને ત્યાં કોઈ મુશ્કેલીઓ નથી.

ખાસ કરીને સરસ વાત એ છે કે આવા સોલ્યુશન સ્થાનિક નેટવર્કના આમૂલ પુનઃડિઝાઇનને સૂચિત કરતું નથી; આ અમારા માટે મહત્વપૂર્ણ હતું; અમારે ન્યૂનતમ ખર્ચ સાથે આનો ઉકેલ લાવવાનો હતો. જો તમે જુઓ IPVS એડમિન કમાન્ડ આઉટપુટ, પછી આપણે જોઈશું કે તે કેવું દેખાય છે. અહીં અમારી પાસે ચોક્કસ વર્ચ્યુઅલ સર્વર છે, પોર્ટ 443 પર, કનેક્શન સાંભળે છે, સ્વીકારે છે, બધા કાર્યકારી સર્વર્સ સૂચિબદ્ધ છે, અને તમે જોઈ શકો છો કે કનેક્શન આપો અથવા લો, સમાન છે. જો આપણે સમાન વર્ચ્યુઅલ સર્વર પરના આંકડાઓ જોઈએ, તો અમારી પાસે ઇનકમિંગ પેકેટ્સ, ઇનકમિંગ કનેક્શન્સ છે, પરંતુ બિલકુલ આઉટગોઇંગ નથી. આઉટગોઇંગ કનેક્શન્સ સીધા ક્લાયન્ટને જાય છે. ઠીક છે, અમે તેને અસંતુલિત કરવામાં સક્ષમ હતા. હવે, જો આપણું એક ફોટો રાઉટર નિષ્ફળ જાય તો શું થાય? છેવટે, આયર્ન લોખંડ છે. તે કર્નલ ગભરાટમાં જઈ શકે છે, તે તૂટી શકે છે, પાવર સપ્લાય બળી શકે છે. કંઈપણ. આ કારણે આરોગ્ય તપાસ જરૂરી છે. તે પોર્ટ કેવી રીતે ખુલ્લું છે તે તપાસવા જેટલું સરળ હોઈ શકે છે, અથવા કંઈક વધુ જટિલ હોઈ શકે છે, કેટલીક હોમ-લિખિત સ્ક્રિપ્ટો સુધી જે વ્યવસાયના તર્કને પણ તપાસશે.

અમે મધ્યમાં ક્યાંક અટકી ગયા: અમારી પાસે ચોક્કસ સ્થાન માટે https વિનંતી છે, સ્ક્રિપ્ટ કહેવામાં આવે છે, જો તે 200મા પ્રતિસાદ સાથે પ્રતિસાદ આપે છે, તો અમે માનીએ છીએ કે આ સર્વર સાથે બધું બરાબર છે, કે તે જીવંત છે અને તદ્દન ચાલુ કરી શકાય છે. સરળતાથી

આ, ફરીથી, વ્યવહારમાં કેવી રીતે દેખાય છે? ચાલો જાળવણી માટે સર્વરને બંધ કરીએ - ઉદાહરણ તરીકે, BIOS ને ફ્લેશ કરવું. લૉગ્સમાં અમારી પાસે તરત જ સમયસમાપ્તિ છે, અમે પ્રથમ લીટી જોઈએ છીએ, પછી ત્રણ પ્રયાસો પછી તેને "નિષ્ફળ" તરીકે ચિહ્નિત કરવામાં આવે છે, અને તે ફક્ત સૂચિમાંથી દૂર કરવામાં આવે છે.

બીજો વર્તણૂક વિકલ્પ પણ શક્ય છે, જ્યારે VS ખાલી શૂન્ય પર સેટ હોય, પરંતુ જો ફોટો પરત કરવામાં આવે, તો આ સારી રીતે કામ કરતું નથી. સર્વર આવે છે, Nginx ત્યાં શરૂ થાય છે, આરોગ્ય-તપાસ તરત જ સમજે છે કે કનેક્શન કામ કરી રહ્યું છે, બધું સારું છે, અને સર્વર અમારી સૂચિમાં દેખાય છે, અને લોડ તરત જ તેના પર લાગુ થવાનું શરૂ કરે છે. ડ્યુટી એડમિનિસ્ટ્રેટર તરફથી કોઈ મેન્યુઅલ ક્રિયાઓની જરૂર નથી. સર્વર રાત્રે રીબૂટ થયું - મોનિટરિંગ વિભાગ રાત્રે આ વિશે અમને કૉલ કરતું નથી. તેઓ તમને જાણ કરે છે કે આ બન્યું છે, બધું સારું છે.

તેથી, એકદમ સરળ રીતે, થોડી સંખ્યામાં સર્વરની મદદથી, અમે બાહ્ય દોષ સહિષ્ણુતાની સમસ્યાને હલ કરી.

એટલું જ કહેવાનું બાકી છે કે આ બધા પર, અલબત્ત, દેખરેખ રાખવાની જરૂર છે. અલગથી, એ નોંધવું જોઈએ કે Keepalivede, જેમ કે લાંબા સમય પહેલા લખાયેલ સોફ્ટવેરમાં, DBus, SMTP, SNMP અને સ્ટાન્ડર્ડ Zabbix દ્વારા ચેકનો ઉપયોગ કરીને તેનું નિરીક્ષણ કરવાની ઘણી રીતો છે. ઉપરાંત, તે પોતે જાણે છે કે લગભગ દરેક છીંક માટે કેવી રીતે પત્રો લખવા, અને પ્રમાણિકપણે, અમુક સમયે અમે તેને બંધ કરવાનું પણ વિચાર્યું, કારણ કે તે દરેક IP કનેક્શન માટે કોઈપણ ટ્રાફિક સ્વિચિંગ, સ્વિચિંગ માટે ઘણા બધા પત્રો લખે છે, અને તેથી વધુ. અલબત્ત, જો ત્યાં ઘણા બધા સર્વર્સ છે, તો પછી તમે આ અક્ષરોથી તમારી જાતને ડૂબી શકો છો. અમે પ્રમાણભૂત પદ્ધતિઓનો ઉપયોગ કરીને ફોટો રાઉટર્સ પર nginx મોનિટર કરીએ છીએ, અને હાર્ડવેર મોનિટરિંગ દૂર થયું નથી. અમે, અલબત્ત, વધુ બે બાબતોની સલાહ આપીશું: પ્રથમ, બાહ્ય આરોગ્ય-તપાસ અને ઉપલબ્ધતા, કારણ કે જો બધું કામ કરે તો પણ, હકીકતમાં, કદાચ વપરાશકર્તાઓને બાહ્ય પ્રદાતાઓની સમસ્યાઓ અથવા કંઈક વધુ જટિલ હોવાને કારણે ફોટા પ્રાપ્ત થતા નથી. તે હંમેશા અન્ય નેટવર્ક પર, એમેઝોનમાં અથવા બીજે ક્યાંક રાખવા યોગ્ય છે, એક અલગ મશીન જે તમારા સર્વરને બહારથી પિંગ કરી શકે છે, અને તે અસંગતતા શોધનો ઉપયોગ કરવા માટે પણ યોગ્ય છે, જેઓ મુશ્કેલ મશીન લર્નિંગ અથવા સરળ દેખરેખ કેવી રીતે કરવું તે જાણે છે. , ઓછામાં ઓછું ટ્રૅક કરવા માટે કે શું વિનંતીઓ તીવ્ર ઘટાડો થયો છે, અથવા, તેનાથી વિપરીત, વધારો થયો છે. તે ઉપયોગી પણ થઈ શકે છે.

ચાલો સારાંશ આપીએ: અમે, હકીકતમાં, આયર્ન-ક્લેડ સોલ્યુશનને બદલ્યું, જે અમુક સમયે અમને અનુકૂળ થવાનું બંધ કરી દીધું, એકદમ સરળ સિસ્ટમ સાથે જે બધું એકસરખું કરે છે, એટલે કે, તે HTTPS ટ્રાફિકને સમાપ્ત કરે છે અને સાથે વધુ સ્માર્ટ રૂટીંગ પ્રદાન કરે છે. જરૂરી આરોગ્ય તપાસો. અમે આ સિસ્ટમની સ્થિરતામાં વધારો કર્યો છે, એટલે કે, અમારી પાસે હજુ પણ દરેક સ્તર માટે ઉચ્ચ ઉપલબ્ધતા છે, ઉપરાંત અમારી પાસે બોનસ છે કે દરેક સ્તર પર તે બધાને સ્કેલ કરવું એકદમ સરળ છે, કારણ કે તે પ્રમાણભૂત સોફ્ટવેર સાથે પ્રમાણભૂત હાર્ડવેર છે, એટલે કે , અમે શક્ય સમસ્યાઓનું નિદાન કરવાનું સરળ બનાવ્યું છે.

અમે શું સાથે અંત આવ્યો? 2018 ની જાન્યુઆરીની રજાઓ દરમિયાન અમને સમસ્યા હતી. પ્રથમ છ મહિનામાં જ્યારે અમે આ સ્કીમને અમલમાં મૂકી હતી, ત્યારે અમે LTMમાંથી તમામ ટ્રાફિકને દૂર કરવા માટે તેને તમામ ટ્રાફિકમાં વિસ્તારી હતી, અમે માત્ર એક ડેટા સેન્ટરમાં ટ્રાફિકમાં 40 ગીગાબિટ્સથી 60 ગીગાબિટ્સ સુધીનો વધારો કર્યો હતો, અને તે જ સમયે સમગ્ર 2018 વર્ષ પ્રતિ સેકન્ડમાં લગભગ ત્રણ ગણા વધુ ફોટા મોકલવામાં સક્ષમ હતા.

સોર્સ: www.habr.com