પોસ્ટગ્રેસ મંગળવાર નંબર 5: “PostgreSQL અને Kubernetes. CI/CD. પરીક્ષણ ઓટોમેશન"

ગયા વર્ષના અંતે, રશિયન PostgreSQL સમુદાયનું બીજું જીવંત પ્રસારણ થયું #RuPostgres, જે દરમિયાન તેના સહ-સ્થાપક નિકોલાઈ સમોખવાલોવે ફ્લાન્ટના ટેકનિકલ ડિરેક્ટર દિમિત્રી સ્ટોલ્યારોવ સાથે કુબરનેટ્સના સંદર્ભમાં આ DBMS વિશે વાત કરી હતી.

અમે આ ચર્ચાના મુખ્ય ભાગની ટ્રાન્સક્રિપ્ટ પ્રકાશિત કરી રહ્યા છીએ, અને મુ સમુદાય YouTube ચેનલ સંપૂર્ણ વિડિયો પોસ્ટ કર્યો:

ડેટાબેસેસ અને કુબરનેટ્સ

НС: અમે આજે વેક્યુમ અને ચેકપોઇન્ટ્સ વિશે વાત કરીશું નહીં. અમે કુબરનેટ્સ વિશે વાત કરવા માંગીએ છીએ. હું જાણું છું કે તમારી પાસે ઘણા વર્ષોનો અનુભવ છે. મેં તમારા વિડિયો જોયા અને તેમાંથી કેટલાકને ફરીથી જોયા પણ... ચાલો સીધા મુદ્દા પર જઈએ: પોસ્ટગ્રેસ અથવા MySQL K8s માં જ શા માટે?

ડીસી: આ પ્રશ્નનો કોઈ ચોક્કસ જવાબ નથી અને હોઈ શકતો નથી. પરંતુ સામાન્ય રીતે, આ સરળતા અને સુવિધા છે... સંભવિત. દરેક વ્યક્તિને વ્યવસ્થાપિત સેવાઓ જોઈએ છે.

НС: કેવી રીતે આરડીએસ, માત્ર ઘરે?

ડીસી: હા: RDS ની જેમ, ગમે ત્યાં.

НС: "ક્યાંય પણ" એ સારો મુદ્દો છે. મોટી કંપનીઓમાં, દરેક વસ્તુ વિવિધ સ્થળોએ સ્થિત છે. તો પછી, જો તે મોટી કંપની છે, તો શા માટે તૈયાર સોલ્યુશન નથી લેતા? ઉદાહરણ તરીકે, Nutanix પાસે તેના પોતાના વિકાસ છે, અન્ય કંપનીઓ (VMware...) પાસે સમાન “RDS, ફક્ત ઘરે જ છે.”

ડીસી: પરંતુ અમે એક અલગ અમલીકરણ વિશે વાત કરી રહ્યા છીએ જે ફક્ત અમુક શરતો હેઠળ જ કાર્ય કરશે. અને જો આપણે કુબરનેટીસ વિશે વાત કરી રહ્યા છીએ, તો ત્યાં ઇન્ફ્રાસ્ટ્રક્ચરની વિશાળ વિવિધતા છે (જે K8s માં હોઈ શકે છે). આવશ્યકપણે આ એપીઆઈ માટે ક્લાઉડ માટેનું માનક છે...

НС: તે પણ મફત છે!

ડીસી: તે એટલું મહત્વનું નથી. બજારના બહુ મોટા ભાગ માટે મુક્તતા મહત્વપૂર્ણ નથી. બીજું કંઈક મહત્વનું છે... તમને કદાચ રિપોર્ટ યાદ હશે.ડેટાબેસેસ અને કુબરનેટ્સ?

НС: હા.

ડીસી: મને સમજાયું કે તે ખૂબ જ અસ્પષ્ટ રીતે પ્રાપ્ત થયું હતું. કેટલાક લોકોએ વિચાર્યું કે હું કહી રહ્યો છું: "ગાય્સ, ચાલો બધા ડેટાબેસેસ કુબરનેટ્સમાં મેળવીએ!", જ્યારે અન્ય લોકોએ નક્કી કર્યું કે આ બધી ભયંકર સાયકલ છે. પરંતુ હું કંઈક સંપૂર્ણપણે અલગ કહેવા માંગતો હતો: “જુઓ શું થઈ રહ્યું છે, ત્યાં કઈ સમસ્યાઓ છે અને તે કેવી રીતે ઉકેલી શકાય છે. શું આપણે હવે કુબરનેટ્સ ડેટાબેસેસનો ઉપયોગ કરવો જોઈએ? ઉત્પાદન? ઠીક છે, માત્ર જો તમને... અમુક વસ્તુઓ કરવાનું પસંદ હોય. પરંતુ દેવ માટે, હું કહી શકું છું કે હું તેની ભલામણ કરું છું. dev માટે, વાતાવરણ બનાવવા/કાઢી નાખવાની ગતિશીલતા ખૂબ જ મહત્વપૂર્ણ છે.”

NS: દેવ દ્વારા, શું તમારો મતલબ એવા બધા વાતાવરણ છે કે જે ઉત્પાદન નથી? સ્ટેજીંગ, QA…

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

НС: કોઈ નહીં. પરંતુ આપણે સ્થિર વાતાવરણ ક્યાં જોઈએ છીએ? એક સ્થિર વાતાવરણ આવતીકાલે અપ્રચલિત થઈ જશે.

ડીસી: સ્ટેજીંગ સ્થિર હોઈ શકે છે. અમારી પાસે ગ્રાહકો છે...

НС: હા, મારી પાસે પણ છે. જો તમારી પાસે 10 TB ડેટાબેઝ અને 200 GB સ્ટેજિંગ હોય તો તે એક મોટી સમસ્યા છે...

ડીસી: મારી પાસે ખૂબ જ સરસ કેસ છે! સ્ટેજીંગ પર એક પ્રોડક્ટ ડેટાબેઝ છે જેમાં ફેરફારો કરવામાં આવે છે. અને ત્યાં એક બટન છે: "પ્રોડક્શન માટે રોલ આઉટ". આ ફેરફારો - ડેલ્ટા - ઉત્પાદનમાં ઉમેરવામાં આવે છે (એવું લાગે છે કે તેઓ ફક્ત API દ્વારા સિંક્રનાઇઝ થયા છે). આ એક ખૂબ જ વિચિત્ર વિકલ્પ છે.

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

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

НС: 100 GB સુધીના આ કદના ડેટાબેઝને સારી ડિસ્ક અને સારા નેટવર્ક પર થોડીવારમાં રોલઆઉટ કરી શકાય છે, ખરું ને? 1 જીબી પ્રતિ સેકન્ડની ઝડપ હવે વિચિત્ર નથી.

ડીસી: હા, રેખીય કામગીરી માટે આ કોઈ સમસ્યા નથી.

НС: ઠીક છે, આપણે ફક્ત ઉત્પાદન વિશે વિચારવું પડશે. અને જો આપણે બિન-ઉત્પાદન વાતાવરણ માટે કુબરનેટ્સને ધ્યાનમાં લઈએ, તો આપણે શું કરવું જોઈએ? હું તે ઝાલેન્ડોમાં જોઉં છું ઓપરેટર કરો, ક્રન્ચીમાં કરવત, કેટલાક અન્ય વિકલ્પો છે. અને ત્યાં છે OnGres - આ સ્પેનનો અમારો સારો મિત્ર અલ્વારો છે: તેઓ જે કરે છે તે આવશ્યકપણે માત્ર નથી ઓપરેટર, અને સમગ્ર વિતરણ (સ્ટેકગ્રેસ), જેમાં, પોસ્ટગ્રેસ પોતે ઉપરાંત, તેઓએ બેકઅપ, દૂત પ્રોક્સી ભરવાનું પણ નક્કી કર્યું...

ડીસી: દૂત શેના માટે? પોસ્ટગ્રેસ ટ્રાફિકને ખાસ સંતુલિત કરી રહ્યાં છો?

НС: હા. એટલે કે, તેઓ તેને આ રીતે જુએ છે: જો તમે Linux વિતરણ અને કર્નલ લો છો, તો પછી નિયમિત PostgreSQL કર્નલ છે, અને તેઓ એક વિતરણ કરવા માંગે છે જે ક્લાઉડ-ફ્રેંડલી હશે અને કુબરનેટ્સ પર ચાલશે. તેઓ ઘટકો (બેકઅપ, વગેરે) એકસાથે મૂકે છે અને તેમને ડીબગ કરે છે જેથી તેઓ સારી રીતે કાર્ય કરે.

ડીસી: ખૂબ જ ઠંડી! આવશ્યકપણે આ તમારા પોતાના સંચાલિત પોસ્ટગ્રેસ બનાવવા માટેનું સોફ્ટવેર છે.

НС: Linux વિતરણોમાં શાશ્વત સમસ્યાઓ છે: ડ્રાઇવરો કેવી રીતે બનાવવું જેથી તમામ હાર્ડવેરને સપોર્ટ મળે. અને તેઓને ખ્યાલ છે કે તેઓ કુબરનેટ્સમાં કામ કરશે. હું જાણું છું કે Zalando ઑપરેટરમાં અમે તાજેતરમાં AWS સાથે કનેક્શન જોયું છે અને તે હવે બહુ સારું નથી. કોઈ ચોક્કસ ઈન્ફ્રાસ્ટ્રક્ચર સાથે જોડાણ ન હોવું જોઈએ - તો પછી મુદ્દો શું છે?

ડીસી: મને ખબર નથી કે ઝાલેન્ડો કઈ પરિસ્થિતિમાં આવી ગયો, પરંતુ કુબરનેટ્સ સ્ટોરેજમાં હવે એવી રીતે બનાવવામાં આવ્યું છે કે સામાન્ય પદ્ધતિનો ઉપયોગ કરીને ડિસ્ક બેકઅપ લેવાનું અશક્ય છે. તાજેતરમાં ધોરણમાં - નવીનતમ સંસ્કરણમાં CSI સ્પષ્ટીકરણો — અમે સ્નેપશોટ શક્ય બનાવ્યા, પરંતુ તેનો અમલ ક્યાં થાય છે? પ્રામાણિકપણે, બધું હજી પણ એટલું કાચું છે... અમે AWS, GCE, Azure, vSphere પર CSI અજમાવી રહ્યા છીએ, પરંતુ તમે તેનો ઉપયોગ કરવાનું શરૂ કરો કે તરત જ તમે જોઈ શકશો કે તે હજી તૈયાર નથી.

НС: એટલા માટે આપણે ક્યારેક ઈન્ફ્રાસ્ટ્રક્ચર પર આધાર રાખવો પડે છે. મને લાગે છે કે આ હજી પ્રારંભિક તબક્કો છે - વધતી જતી પીડા. પ્રશ્ન: K8s માં PgSQL અજમાવવા માંગતા નવાબીઓને તમે શું સલાહ આપશો? શું ઓપરેટર કદાચ?

ડીસી: સમસ્યા એ છે કે પોસ્ટગ્રેસ અમારા માટે 3% છે. અમારી પાસે કુબરનેટ્સમાં વિવિધ સૉફ્ટવેરની ખૂબ મોટી સૂચિ પણ છે, હું બધું સૂચિબદ્ધ પણ કરીશ નહીં. ઉદાહરણ તરીકે, Elasticsearch. ત્યાં ઘણા બધા ઓપરેટરો છે: કેટલાક સક્રિય રીતે વિકાસ કરી રહ્યા છે, અન્ય નથી. અમે તેને ગંભીરતાથી લઈએ તે માટે ઑપરેટર પાસે શું હોવું જોઈએ તે વિશે અમે અમારા માટે જરૂરિયાતો તૈયાર કરી છે. ઓપરેટરમાં ખાસ કરીને કુબરનેટ્સ માટે - "એમેઝોનની પરિસ્થિતિઓમાં કંઈક કરવા માટે ઓપરેટર" માં નહીં... હકીકતમાં, અમે તદ્દન વ્યાપકપણે (= લગભગ તમામ ક્લાયન્ટ્સ) એક જ ઓપરેટરનો ઉપયોગ કરીએ છીએ - રેડિસ માટે (અમે તેના વિશે ટૂંક સમયમાં એક લેખ પ્રકાશિત કરીશું).

НС: અને MySQL માટે પણ નહીં? હું જાણું છું કે Percona... કારણ કે તેઓ હવે MySQL, MongoDB, અને Postgres પર કામ કરી રહ્યા છે, તેથી તેઓએ અમુક પ્રકારના સાર્વત્રિક ઉકેલ બનાવવા પડશે: બધા ડેટાબેસેસ માટે, બધા ક્લાઉડ પ્રદાતાઓ માટે.

ડીસી: અમારી પાસે MySQL માટે ઓપરેટરોને જોવાનો સમય નથી. આ અત્યારે અમારું મુખ્ય ધ્યાન નથી. MySQL સ્ટેન્ડઅલોનમાં સારું કામ કરે છે. જો તમે માત્ર ડેટાબેઝ લોન્ચ કરી શકો તો ઓપરેટરનો ઉપયોગ શા માટે કરો... તમે પોસ્ટર્જેસ સાથે ડોકર કન્ટેનર લોંચ કરી શકો છો, અથવા તમે તેને સરળ રીતે લોન્ચ કરી શકો છો.

НС: આ વિશે પણ એક પ્રશ્ન હતો. કોઈ ઓપરેટર જ નથી?

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

કુબરનેટ્સમાં પરીક્ષણ માટે ડી.બી

НС: ચાલો પરીક્ષણના વિષય પર આગળ વધીએ. ડેવઓપ્સ પરિપ્રેક્ષ્યમાં - ડેટાબેઝમાં ફેરફારો કેવી રીતે રોલ આઉટ કરવા. ત્યાં માઇક્રોસર્વિસિસ છે, ઘણા ડેટાબેસેસ છે, દરેક સમયે ક્યાંક ને ક્યાંક બદલાતી રહે છે. સામાન્ય CI/CD કેવી રીતે સુનિશ્ચિત કરવું કે જેથી DBMS દ્રષ્ટિકોણથી બધું ક્રમમાં હોય. તમારો અભિગમ શું છે?

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

НС: અને GDPR ની શરતો હેઠળ, મને લાગે છે કે તેઓ વધુને વધુ સાવચેત થઈ રહ્યા છે... હું કહી શકું છું કે યુરોપમાં તેઓએ પહેલેથી જ દંડ લાદવાનું શરૂ કરી દીધું છે.

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

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

НС: સાદી નકલ કરીને?

ડીસી: ડેટા સીધો જ ડોકર ઈમેજમાં સંગ્રહિત થાય છે. તે. અમારી પાસે 100 GB હોવા છતાં, તૈયાર છબી છે. ડોકરમાં સ્તરો માટે આભાર, અમે આ છબીને જેટલી વખત જરૂર હોય તેટલી ઝડપથી જમાવી શકીએ છીએ. પદ્ધતિ મૂર્ખ છે, પરંતુ તે સારી રીતે કાર્ય કરે છે.

НС: પછી, જ્યારે તમે પરીક્ષણ કરો છો, ત્યારે તે ડોકરની અંદર જ બદલાય છે, ખરું ને? ડોકરની અંદર કૉપિ-ઑન-રાઇટ કરો - તેને ફેંકી દો અને ફરીથી જાઓ, બધું સારું છે. વર્ગ! અને શું તમે પહેલાથી જ તેનો સંપૂર્ણ ઉપયોગ કરી રહ્યાં છો?

ડીસી: ઘણા સમય સુધી.

НС: અમે ઘણી સમાન વસ્તુઓ કરીએ છીએ. ફક્ત અમે ડોકરની કૉપિ-ઑન-રાઇટનો ઉપયોગ કરતા નથી, પરંતુ અન્ય કોઈનો ઉપયોગ કરીએ છીએ.

ડીસી: તે સામાન્ય નથી. અને ડોકર દરેક જગ્યાએ કામ કરે છે.

НС: સિદ્ધાંતમાં, હા. પરંતુ અમારે ત્યાં મોડ્યુલો પણ છે, તમે અલગ અલગ મોડ્યુલ બનાવી શકો છો અને વિવિધ ફાઇલ સિસ્ટમ સાથે કામ કરી શકો છો. અહીં શું ક્ષણ. પોસ્ટગ્રેસ બાજુથી, આપણે આ બધાને અલગ રીતે જોઈએ છીએ. હવે મેં ડોકર બાજુથી જોયું અને જોયું કે બધું તમારા માટે કામ કરે છે. પરંતુ જો ડેટાબેઝ વિશાળ છે, ઉદાહરણ તરીકે, 1 ટીબી, તો આ બધું લાંબો સમય લે છે: રાત્રે ઓપરેશન, અને ડોકરમાં બધું સ્ટફ કરવું... અને જો 5 ટીબી ડોકરમાં સ્ટફ કરવામાં આવે તો... અથવા બધું સારું છે?

ડીસી: શું તફાવત છે: આ બ્લોબ્સ છે, માત્ર બિટ્સ અને બાઇટ્સ.

НС: તફાવત આ છે: શું તમે તેને ડમ્પ અને પુનઃસ્થાપિત કરો છો?

ડીસી: બિલકુલ જરૂરી નથી. આ છબી બનાવવા માટેની પદ્ધતિઓ અલગ અલગ હોઈ શકે છે.

НС: કેટલાક ક્લાયન્ટ્સ માટે, અમે તેને એવું બનાવ્યું છે કે નિયમિતપણે બેઝ ઈમેજ બનાવવાને બદલે, અમે તેને સતત અદ્યતન રાખીએ છીએ. તે અનિવાર્યપણે એક પ્રતિકૃતિ છે, પરંતુ તે સીધા માસ્ટર પાસેથી નહીં, પરંતુ આર્કાઇવ દ્વારા ડેટા મેળવે છે. દ્વિસંગી આર્કાઇવ જ્યાં WALs દરરોજ ડાઉનલોડ થાય છે, જ્યાં બેકઅપ લેવામાં આવે છે... આ WALs પછી સહેજ વિલંબ સાથે (શાબ્દિક રીતે 1-2 સેકન્ડ) બેઝ ઈમેજ સુધી પહોંચે છે. અમે તેમાંથી કોઈપણ રીતે ક્લોન કરીએ છીએ - હવે અમારી પાસે મૂળભૂત રીતે ZFS છે.

ડીસી: પરંતુ ZFS સાથે તમે એક નોડ સુધી મર્યાદિત છો.

НС: હા. પરંતુ ZFS પાસે જાદુઈ પણ છે મોકલી: તેની સાથે તમે સ્નેપશોટ મોકલી શકો છો અને તે પણ (મેં ખરેખર આનું પરીક્ષણ કર્યું નથી, પણ...) તમે બે વચ્ચેનો ડેલ્ટા મોકલી શકો છો PGDATA. વાસ્તવમાં, અમારી પાસે બીજું એક સાધન છે જેનો અમે આવા કાર્યો માટે ખરેખર વિચાર કર્યો નથી. PostgreSQL પાસે છે pg_rewind, જે "સ્માર્ટ" rsync ની જેમ કામ કરે છે, તમારે જે જોવાનું નથી તે ઘણું બધું છોડી દે છે, કારણ કે ત્યાં કંઈપણ બદલાયું નથી. અમે બે સર્વર વચ્ચે ઝડપી સિંક્રનાઇઝેશન કરી શકીએ છીએ અને તે જ રીતે રીવાઇન્ડ કરી શકીએ છીએ.

તેથી, આનાથી, વધુ DBA બાજુથી, અમે એક સાધન બનાવવાનો પ્રયાસ કરી રહ્યા છીએ જે અમને તમે કહ્યું તે જ કરવા દે છે: અમારી પાસે એક ડેટાબેઝ છે, પરંતુ અમે લગભગ એક સાથે 50 વખત કંઈક ચકાસવા માંગીએ છીએ.

ડીસી: 50 વખત એટલે કે તમારે 50 સ્પોટ ઇન્સ્ટન્સ ઓર્ડર કરવાની જરૂર છે.

НС: ના, અમે એક જ મશીન પર બધું કરીએ છીએ.

ડીસી: પરંતુ જો આ એક ડેટાબેઝ ટેરાબાઈટ હોય તો તમે 50 વખત કેવી રીતે વિસ્તૃત કરશો. મોટે ભાગે તેણીને શરતી 256 જીબી રેમની જરૂર છે?

НС: હા, ક્યારેક તમને ઘણી યાદશક્તિની જરૂર પડે છે - તે સામાન્ય છે. પરંતુ આ જીવનમાંથી એક ઉદાહરણ છે. પ્રોડક્શન મશીનમાં 96 કોર અને 600 જીબી છે. તે જ સમયે, ડેટાબેઝ માટે 32 કોરો (હવે 16 કોર પણ) અને 100-120 GB મેમરીનો ઉપયોગ થાય છે.

ડીસી: અને ત્યાં 50 નકલો ફિટ છે?

НС: તો ત્યાં માત્ર એક જ નકલ છે, પછી કોપી-ઓન-રાઈટ (ZFS) કામ કરે છે... હું તમને વધુ વિગતવાર જણાવીશ.

ઉદાહરણ તરીકે, અમારી પાસે 10 TB ડેટાબેઝ છે. તેઓએ તેના માટે એક ડિસ્ક બનાવી, ZFS એ તેના કદને 30-40 ટકાથી સંકુચિત પણ કર્યું. અમે લોડ પરીક્ષણ કરતા ન હોવાથી, ચોક્કસ પ્રતિભાવ સમય અમારા માટે મહત્વપૂર્ણ નથી: તેને 2 ગણો ધીમો થવા દો - તે ઠીક છે.

અમે પ્રોગ્રામરો, QA, DBA, વગેરેને તક આપીએ છીએ. 1-2 થ્રેડોમાં પરીક્ષણ કરો. ઉદાહરણ તરીકે, તેઓ અમુક પ્રકારનું સ્થળાંતર ચલાવી શકે છે. તેને એક જ સમયે 10 કોરોની જરૂર નથી - તેને 1 પોસ્ટગ્રેસ બેકએન્ડ, 1 કોરની જરૂર છે. સ્થળાંતર શરૂ થશે - કદાચ ઓટોવેક્યુમ હજુ પણ શરૂ થશે, પછી બીજા કોરનો ઉપયોગ કરવામાં આવશે. અમારી પાસે 16-32 કોરો ફાળવવામાં આવ્યા છે, તેથી 10 લોકો એક જ સમયે કામ કરી શકે છે, કોઈ સમસ્યા નથી.

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

પરંતુ અમુક સમયે અમને સમજાયું કે આ જરૂરી નથી: અમે શેર કરેલ_બફર્સને 2 જીબી પર સેટ કર્યા છે. PostgreSQL પાસે છે અસરકારક_કેશ_સાઇઝ, અને વાસ્તવમાં તે માત્ર એક જ છે જે પ્રભાવિત કરે છે યોજનાઓ. અમે તેને 0,5 TB પર સેટ કરીએ છીએ. અને તે પણ વાંધો નથી કે તેઓ ખરેખર અસ્તિત્વમાં નથી: તે યોજનાઓ બનાવે છે જાણે કે તેઓ અસ્તિત્વમાં હોય.

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

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

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

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

ડીસી: મારા દૃષ્ટિકોણથી, અમે કુબરનેટ્સમાં શીંગો બનાવીએ છીએ. K8s - સ્થિતિસ્થાપક: જરૂર મુજબ ગાંઠો ઓર્ડર કરવામાં આવે છે. કાર્ય ફક્ત પોડ બનાવવાનું છે અને કહેવાનું છે કે તેને સંસાધનોની X રકમની જરૂર છે, અને પછી K8s તેને જાતે શોધી કાઢશે. પરંતુ કુબરનેટ્સમાં સ્ટોરેજ સપોર્ટ હજી પણ અસ્થિર છે: 1.16માં 1.17 (આ પ્રકાશન બહાર પાડવામાં આવ્યું હતું અઠવાડિયાના પહેલા) આ સુવિધાઓ માત્ર બીટા બની જાય છે.

છ મહિનાથી એક વર્ષ પસાર થશે - તે વધુ કે ઓછું સ્થિર બનશે, અથવા ઓછામાં ઓછું તે જેમ જાહેર કરવામાં આવશે. પછી સ્નેપશોટ અને માપ બદલવાની શક્યતા તમારી સમસ્યાને સંપૂર્ણપણે હલ કરે છે. કારણ કે તમારી પાસે આધાર છે. હા, તે ખૂબ ઝડપી ન હોઈ શકે, પરંતુ ઝડપ "હૂડ હેઠળ" શું છે તેના પર આધાર રાખે છે, કારણ કે કેટલાક અમલીકરણો ડિસ્ક સબસિસ્ટમ સ્તર પર કૉપિ અને કૉપિ-ઑન-રાઇટ કરી શકે છે.

НС: બધા એન્જિનો (Amazon, Google...) માટે આ સંસ્કરણને સમર્થન આપવાનું શરૂ કરવું પણ જરૂરી છે - આમાં થોડો સમય પણ લાગે છે.

ડીસી: અમે હજુ સુધી તેનો ઉપયોગ કરતા નથી. અમે અમારા ઉપયોગ.

કુબરનેટ્સ માટે સ્થાનિક વિકાસ

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

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

НС: મને લાગતું હતું કે આ એક ડોકર ઇમેજમાં તમામ શીંગો લપેટવાનો પ્રયાસ હતો. પરંતુ તે બહાર આવ્યું છે કે આ સંપૂર્ણપણે અલગ કંઈક વિશે છે. કોઈપણ રીતે, ત્યાં અલગ કન્ટેનર, અલગ શીંગો છે - ફક્ત ડોકરમાં.

ડીસી: હા. અને ત્યાં એક રમુજી અનુકરણ કરવામાં આવ્યું છે, પરંતુ અર્થ એ છે કે... અમારી પાસે જમાવટ માટે ઉપયોગિતા છે - વર્ફ. અમે તેને શરતી મોડ બનાવવા માંગીએ છીએ werf up: "મને સ્થાનિક કુબરનેટ્સ મેળવો." અને પછી ત્યાં શરતી ચલાવો werf follow. પછી વિકાસકર્તા IDE ને સંપાદિત કરવામાં સક્ષમ હશે, અને સિસ્ટમમાં એક પ્રક્રિયા શરૂ કરવામાં આવશે જે ફેરફારોને જુએ છે અને છબીઓનું પુનઃનિર્માણ કરે છે, તેને સ્થાનિક K8s પર ફરીથી ગોઠવે છે. આ રીતે અમે સ્થાનિક વિકાસની સમસ્યાને હલ કરવાનો પ્રયાસ કરવા માંગીએ છીએ.

K8s વાસ્તવિકતામાં સ્નેપશોટ અને ડેટાબેઝ ક્લોનિંગ

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

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

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

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

НС: પરંતુ તે હજુ પણ તેમને સેકન્ડો લેશે, દાખલો ઉભો કરવામાં, ડોકરને ત્યાં લાવવામાં, વગેરે.

ડીસી: આખો દાખલો ઊભો કરવો શા માટે જરૂરી છે? અમારી પાસે 32 કોરો, 16... સાથેનો દાખલો છે અને તે તેમાં ફિટ થઈ શકે છે - ઉદાહરણ તરીકે, ચાર. જ્યારે આપણે પાંચમાને ઓર્ડર કરીએ છીએ, ત્યારે દાખલો પહેલેથી જ ઉભો કરવામાં આવશે, અને પછી તે કાઢી નાખવામાં આવશે.

НС: હા, રસપ્રદ, કુબરનેટીસ એક અલગ વાર્તા હોવાનું બહાર આવ્યું છે. અમારો ડેટાબેઝ K8s માં નથી, અને અમારી પાસે એક ઉદાહરણ છે. પરંતુ મલ્ટિ-ટેરાબાઇટ ડેટાબેઝને ક્લોન કરવામાં બે સેકન્ડથી વધુ સમય લાગતો નથી.

ડીસી: આ મહાન છે. પરંતુ મારો પ્રારંભિક મુદ્દો એ છે કે આ એક સામાન્ય ઉકેલ નથી. હા, તે સરસ છે, પરંતુ તે માત્ર પોસ્ટગ્રેસ માટે અને માત્ર એક નોડ પર જ યોગ્ય છે.

НС: તે માત્ર પોસ્ટગ્રેસ માટે જ યોગ્ય નથી: આ યોજનાઓ, જેમ મેં વર્ણવ્યું છે, તે ફક્ત તેમાં જ કાર્ય કરશે. પરંતુ જો આપણે યોજનાઓ વિશે ચિંતા ન કરીએ, અને અમને ફક્ત કાર્યાત્મક પરીક્ષણ માટે તમામ ડેટાની જરૂર હોય, તો આ કોઈપણ DBMS માટે યોગ્ય છે.

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

НС: શું તમને અહીં સંકરની કોઈ શક્યતા દેખાય છે? ચાલો કહીએ કે સ્ટેટફુલ એક પ્રકારનું પોડ છે, તે ઘણા લોકો (ઘણા પરીક્ષકો) માટે કામ કરે છે. અમારી પાસે એક વોલ્યુમ છે, પરંતુ ફાઇલ સિસ્ટમનો આભાર, ક્લોન્સ સ્થાનિક છે. જો પોડ પડે છે, પરંતુ ડિસ્ક રહે છે, તો પોડ વધશે, બધા ક્લોન્સ વિશેની માહિતીની ગણતરી કરો, બધું ફરીથી પસંદ કરો અને કહો: "આ પોર્ટ્સ પર તમારા ક્લોન્સ ચાલી રહ્યા છે, તેમની સાથે કામ કરવાનું ચાલુ રાખો."

ડીસી: તકનીકી રીતે આનો અર્થ એ છે કે કુબરનેટ્સની અંદર તે એક પોડ છે જેની અંદર આપણે ઘણા પોસ્ટગ્રેસ ચલાવીએ છીએ.

НС: હા. તેની મર્યાદા છે: ચાલો કહીએ કે એક જ સમયે તેની સાથે 10 થી વધુ લોકો કામ ન કરે. જો તમને 20ની જરૂર હોય, તો અમે આવી બીજી પોડ લોન્ચ કરીશું. અમે તેને સંપૂર્ણપણે ક્લોન કરીશું, બીજું સંપૂર્ણ વોલ્યુમ પ્રાપ્ત કર્યા પછી, તેમાં સમાન 10 "પાતળા" ક્લોન્સ હશે. શું તમને આ તક દેખાતી નથી?

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

НС: હું ઘણા ટેરાબાઈટ માટે દોઢ સેકન્ડમાં માનતો નથી. Ceph પર તમે તે જાતે કરો છો, પરંતુ તમે વાદળો વિશે વાત કરો છો. ક્લાઉડ પર જાઓ, EC2 પર મલ્ટિ-ટેરાબાઇટ EBS વોલ્યુમનો ક્લોન બનાવો અને જુઓ કે પ્રદર્શન શું હશે. તે થોડી સેકંડ લેશે નહીં. તેઓ આ સ્તરે ક્યારે પહોંચશે તેમાં મને ખૂબ જ રસ છે. તમે શું કહો છો તે હું સમજું છું, પણ હું અલગ રહેવાની વિનંતી કરું છું.

ડીસી: ઓકે, પણ મેં મધ્યમ ગાળામાં કહ્યું, ટૂંકા ગાળામાં નહીં. ઘણા વર્ષો સુધી.

Zalando તરફથી PostgreSQL માટે ઓપરેટર વિશે

આ મીટિંગની મધ્યમાં, ઝાલેન્ડોના ભૂતપૂર્વ ડેવલપર, એલેક્સી ક્લ્યુકિન પણ જોડાયા અને પોસ્ટગ્રેએસક્યુએલ ઓપરેટરના ઇતિહાસ વિશે વાત કરી:

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

“વ્યવસ્થિત સેવાઓ પર જાઓ અને તેનો ઉપયોગ કરો, કુબરનેટ્સમાં ડેટાબેઝ ચલાવશો નહીં. નહિંતર, તમારા K8s નક્કી કરશે, ઉદાહરણ તરીકે, અપગ્રેડ કરવા માટે, બધા નોડ્સ બંધ કરો અને તમારો ડેટા દૂર દૂર સુધી ઉડી જશે.”

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

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

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

અને અમારી પાસે પહેલેથી જ એક ડોકર કન્ટેનર હતું. ત્યાં એક PaaS હતો જેણે Dockerનો ઉપયોગ કર્યો હતો. શા માટે K8s અજમાવશો નહીં? શા માટે તમારા પોતાના ઓપરેટર લખતા નથી? મુરત કાબિલોવ, જે અવિટોથી અમારી પાસે આવ્યા હતા, તેમણે પોતાની પહેલ પર એક પ્રોજેક્ટ તરીકે આની શરૂઆત કરી - "રમવા માટે" - અને પ્રોજેક્ટ "ઉપડ્યો."

પરંતુ સામાન્ય રીતે, હું AWS વિશે વાત કરવા માંગતો હતો. શા માટે ત્યાં ઐતિહાસિક AWS સંબંધિત કોડ હતો...

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

તેથી, જ્યારે અમે નિવેદન કર્યું, ત્યારે અમારી પાસે પોસ્ટગ્રેસ બાહ્ય વોલ્યુમ પર ચાલતું હતું (આ કિસ્સામાં EBS, કારણ કે અમે AWS પર કામ કરતા હતા). ડેટાબેઝ વધ્યો, અમુક સમયે તેનું કદ બદલવું જરૂરી હતું: ઉદાહરણ તરીકે, EBS નું પ્રારંભિક કદ 100 TB હતું, ડેટાબેઝ તેના સુધી વધ્યો, હવે અમે EBS 200 TB બનાવવા માંગીએ છીએ. કેવી રીતે? ચાલો કહીએ કે તમે નવા દાખલા પર ડમ્પ/રીસ્ટોર કરી શકો છો, પરંતુ આમાં ઘણો સમય લાગશે અને ડાઉનટાઇમનો સમાવેશ થશે.

તેથી, મને એક પુન: માપ જોઈતું હતું જે EBS પાર્ટીશનને વધારશે અને પછી ફાઇલ સિસ્ટમને નવી જગ્યા વાપરવા માટે કહે. અને અમે તે કર્યું, પરંતુ તે સમયે કુબરનેટ્સ પાસે રીસાઈઝ ઓપરેશન માટે કોઈ API નહોતું. અમે AWS પર કામ કર્યું હોવાથી, અમે તેના API માટે કોડ લખ્યો છે.

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

પી.એસ. બોનસ!

જો તમને PostgreSQL અને Kubernetes વિષયમાં રસ હોય, તો કૃપા કરીને એ પણ નોંધો કે આગલું પોસ્ટગ્રેસ મંગળવાર ગયા અઠવાડિયે થયું હતું, જ્યાં મેં નિકોલાઈ સાથે વાત કરી હતી. ઝાલેન્ડોથી એલેક્ઝાંડર કુકુશકીન. તેમાંથી વિડિયો ઉપલબ્ધ છે અહીં.

પી.પી.એસ.

અમારા બ્લોગ પર પણ વાંચો:

• «ડેટાબેસેસ અને કુબરનેટ્સ (સમીક્ષા અને વિડિયો રિપોર્ટ)»;
• «કસાન્ડ્રાનું કુબરનેટ્સમાં સ્થળાંતર: સુવિધાઓ અને ઉકેલો»;
• «મોંગોડીબીનું કુબરનેટ્સમાં સીમલેસ સ્થળાંતર»;
• «RabbitMQ નું કુબરનેટ્સમાં સીમલેસ સ્થળાંતર».

સોર્સ: www.habr.com