පසුගිය වසර අවසානයේදී රුසියානු PostgreSQL ප්‍රජාවේ තවත් සජීවී විකාශනයක් සිදු විය , එහි සම-නිර්මාතෘ Nikolai Samokhvalov Kubernetes සන්දර්භය තුළ මෙම DBMS ගැන Flant තාක්ෂණික අධ්යක්ෂ Dmitry Stolyarov සමඟ කතා කරන අතරතුර.
අපි මෙම සාකච්ඡාවේ ප්රධාන කොටසේ පිටපතක් ප්‍රකාශයට පත් කරමින් සිටිමු සම්පූර්ණ වීඩියෝව පළ කර ඇත:
දත්ත සමුදායන් සහ Kubernetes
НС: අපි අද VACUUM සහ CHECKPOINT ගැන කතා නොකරමු. අපි Kubernetes ගැන කතා කරන්න ඕන. ඔබට වසර ගණනාවක අත්දැකීම් ඇති බව මම දනිමි. මම ඔබේ වීඩියෝ නරඹා ඒවායින් සමහරක් නැවත නැරඹුවෙමි... අපි කෙලින්ම කාරණයට යමු: K8s හි Postgres හෝ MySQL ඇයි?
ඩී.එස්: මෙම ප්‍රශ්නයට නිශ්චිත පිළිතුරක් නොමැති අතර විය නොහැක. නමුත් පොදුවේ, මෙය සරල බව සහ පහසුව ... විභවය. සෑම කෙනෙකුටම කළමනාකරණය කළ සේවාවන් අවශ්‍යයි.
НС: කෙසේද , ගෙදර විතරද?
ඩී.එස්: ඔව්: RDS වගේ, ඕනෑම තැනක.
НС: "ඕනෑම තැනක" හොඳ කරුණක්. විශාල සමාගම්වල සෑම දෙයක්ම විවිධ ස්ථානවල පිහිටා ඇත. එසේ නම්, එය විශාල සමාගමක් නම්, සූදානම් කළ විසඳුමක් නොගන්නේ මන්ද? උදාහරණයක් ලෙස, Nutanix හට තමන්ගේම වර්ධනයන් ඇත, වෙනත් සමාගම් (VMware...) එකම "RDS, නිවසේ පමණක්" ඇත.
ඩී.එස්: නමුත් අපි කතා කරන්නේ යම් යම් කොන්දේසි යටතේ පමණක් ක්රියාත්මක වන වෙනම ක්රියාත්මක කිරීමක් ගැන ය. අපි Kubernetes ගැන කතා කරන්නේ නම්, විශාල විවිධ යටිතල පහසුකම් ඇත (එය K8 වල විය හැකිය). අත්‍යවශ්‍යයෙන්ම මෙය API සඳහා ක්ලවුඩ් සඳහා ප්‍රමිතියකි...
НС: එය ද නොමිලේ!
ඩී.එස්: එය එතරම් වැදගත් නොවේ. වෙළඳපොලේ ඉතා විශාල කොටසකට නොව නිදහස වැදගත් වේ. තවත් දෙයක් වැදගත්... ඔබට සමහර විට වාර්තාව මතක ඇති."?
НС: ඔව්.
ඩී.එස්: එය ඉතා අපැහැදිලි ලෙස ලැබුණු බව මට වැටහුණි. සමහර අය හිතුවේ මම මෙහෙම කියනවා කියලා: "යාලුවනේ, අපි සියලු දත්ත සමුදායන් Kubernetes වෙත ගෙන යමු!", තවත් සමහරු මේ සියල්ල භයානක බයිසිකල් බව තීරණය කළහ. නමුත් මට සම්පූර්ණයෙන්ම වෙනස් දෙයක් පැවසීමට අවශ්ය විය: “බලන්න, සිදුවන්නේ කුමක්ද, කුමන ගැටලු තිබේද සහ ඒවා විසඳිය හැකි ආකාරය බලන්න. අපි දැන් Kubernetes දත්ත සමුදායන් භාවිතා කළ යුතුද? නිෂ්පාදනය? හොඳයි, ඔබ කැමති නම් පමණක්... යම් යම් දේවල් කිරීම. නමුත් සංවර්ධකයෙකු සඳහා, මම එය නිර්දේශ කරන බව මට පැවසිය හැකිය. සංවර්ධකයෙකු සඳහා, පරිසරයන් නිර්මාණය කිරීමේ/මකා දැමීමේ ගතිකත්වය ඉතා වැදගත් වේ.
NS: dev යන්නෙන්, ඔබ අදහස් කරන්නේ ප්‍රොඩ් නොවන සියලුම පරිසරයන්ද? වේදිකාගත කිරීම, QA…
ඩී.එස්: අපි කතා කරන්නේ පර්ෆ් ස්ටෑන්ඩ් ගැන නම්, බොහෝ විට එසේ නොවේ, මන්ද එහි අවශ්‍යතා විශේෂිත බැවිනි. අපි කතා කරන්නේ වේදිකාගත කිරීම සඳහා ඉතා විශාල දත්ත ගබඩාවක් අවශ්ය වන විශේෂ අවස්ථා ගැන නම්, බොහෝ විට එසේ නොවේ ... මෙය ස්ථිතික, දිගුකාලීන පරිසරයක් නම්, දත්ත සමුදාය K8s හි පිහිටා තිබීමෙන් ඇති ප්‍රයෝජනය කුමක්ද?
НС: කිසිවක් නැත. නමුත් අපි ස්ථිතික පරිසරයන් දකින්නේ කොහේද? ස්ථිතික පරිසරයක් හෙට යල්පැන යනු ඇත.
ඩී.එස්: වේදිකාගත කිරීම ස්ථිතික විය හැකිය. අපට ගනුදෙනුකරුවන් සිටී ...
НС: ඔව්, මටත් එකක් තියෙනවා. ඔබට 10 TB දත්ත ගබඩාවක් සහ 200 GB වේදිකාගත කිරීමක් තිබේ නම් එය විශාල ගැටළුවකි.
ඩී.එස්: මට ඉතා සිසිල් නඩුවක් තිබේ! වේදිකාගත කිරීමේදී වෙනස්කම් සිදු කරන නිෂ්පාදන දත්ත ගබඩාවක් ඇත. බොත්තමක් තිබේ: "නිෂ්පාදනයට පෙරළන්න". මෙම වෙනස්කම් - ඩෙල්ටා - නිෂ්පාදනයේදී එකතු කරනු ලැබේ (ඒවා සරලව API හරහා සමමුහුර්ත කර ඇති බව පෙනේ). මෙය ඉතා විදේශීය විකල්පයකි.
НС: මම නිම්නයේ RDS හි හෝ Heroku හි පවා සිටින ආරම්භකයින් දැක ඇත - මේවා මීට වසර 2-3 කට පෙර කථා - සහ ඔවුන් තම ලැප්ටොප් පරිගණකයට ඩම්ප් බාගත කරති. දත්ත සමුදාය තවමත් 80 GB පමණක් වන අතර, ලැප්ටොප් පරිගණකයේ ඉඩ ඇත. එවිට ඔවුන් සෑම කෙනෙකුටම අමතර තැටි මිලදී ගන්නා අතර එමඟින් විවිධ වර්ධනයන් සිදු කිරීමට දත්ත සමුදායන් 3 ක් ඇත. ඒකත් වෙන්නේ මෙහෙමයි. නිෂ්පාදනය වේදිකාගත කිරීමට ඔවුන් බිය නොවන බව ද මම දුටුවෙමි - එය බොහෝ දුරට සමාගම මත රඳා පවතී. නමුත් ඔවුන් ඉතා බියෙන් සිටින බවත්, ඔවුන්ට බොහෝ විට ප්‍රමාණවත් කාලයක් සහ අතක් නොමැති බවත් මම දුටුවෙමි. නමුත් අපි මෙම මාතෘකාවට යාමට පෙර, මම Kubernetes ගැන අහන්න කැමතියි. තවම කිසිවෙක් ප්‍රොඩ් එකේ නැති බව මට නිවැරදිව තේරෙනවාද?
ඩී.එස්: අපට නිෂ්පාදනයේ කුඩා දත්ත සමුදායන් ඇත. අපි කතා කරන්නේ ගිගාබයිට් දස ගණනක පරිමාවන් සහ විවේචනාත්මක නොවන සේවාවන් සඳහා අනුරූ සෑදීමට අප කම්මැලි වූ (සහ එවැනි අවශ්‍යතාවයක් නැත). Kubernetes යටතේ සාමාන්ය ගබඩාවක් ඇති බව සපයා ඇත. මෙම දත්ත සමුදාය අථත්‍ය යන්ත්‍රයක ක්රියා කරයි - කොන්දේසි සහිතව VMware හි, ගබඩා පද්ධතියට ඉහළින්. අපි ඒක දැම්මා දැන් අපට එය යන්ත්‍රයෙන් යන්ත්‍රයට මාරු කළ හැකිය.
НС: මේ ප්‍රමාණයේ, 100 GB දක්වා දත්ත සමුදායන්, හොඳ තැටි සහ හොඳ ජාලයක් මත මිනිත්තු කිහිපයකින් රෝල් කරන්න පුළුවන් නේද? තත්පරයකට 1 GB වේගයක් තවදුරටත් විදේශීය නොවේ.
ඩී.එස්: ඔව්, රේඛීය මෙහෙයුම සඳහා මෙය ගැටළුවක් නොවේ.
НС: හරි, අපිට හිතන්න තියෙන්නේ prod ගැන විතරයි. සහ අපි නිෂ්පාදන නොවන පරිසරයන් සඳහා Kubernetes සලකා බලන්නේ නම්, අප කළ යුත්තේ කුමක්ද? මම ඒක දකින්නේ Zalando වල , Crunchy දී , වෙනත් විකල්ප කිහිපයක් තිබේ. ඒ වගේම තියෙනවා - මේ ස්පාඤ්ඤයේ අපේ හොඳ මිතුරා අල්වාරෝ ය: ඔවුන් කරන දේ අත්‍යවශ්‍යයෙන්ම නිකම්ම නොවේ , සහ සම්පූර්ණ බෙදාහැරීම (), එයට, Postgres ට අමතරව, ඔවුන් උපස්ථයක් පුරවා ගැනීමට ද තීරණය කළහ, එන්වෝයි ප්‍රොක්සි...
ඩී.එස්: දූතයා කුමක් සඳහාද? Postgres ගමනාගමනය විශේෂයෙන් සමබර කිරීම?
НС: ඔව්. එනම්, ඔවුන් එය දකින්නේ: ඔබ Linux බෙදාහැරීමක් සහ කර්නලයක් ගන්නේ නම්, සාමාන්ය PostgreSQL යනු කර්නලය වන අතර, ඔවුන්ට අවශ්ය වන්නේ වලාකුළු-හිතකාමී සහ Kubernetes මත ක්රියාත්මක වන බෙදාහැරීමක් කිරීමටයි. ඔවුන් සංරචක (බැකප්, ආදිය) එකට එකතු කර ඒවා හොඳින් ක්රියාත්මක වන පරිදි දෝෂහරණය කරයි.
ඩී.එස්: ඉතා සිසිල්! අත්‍යවශ්‍යයෙන්ම මෙය ඔබේම කළමනාකරණය කළ Postgres නිර්මාණය කිරීමට මෘදුකාංගයකි.
НС: ලිනක්ස් බෙදාහැරීම් සදාකාලික ගැටළු ඇත: සියලුම දෘඩාංග සඳහා සහය වන පරිදි ධාවක සාදා ගන්නේ කෙසේද. තවද ඔවුන් කුබර්නෙටස් හි වැඩ කරනු ඇතැයි යන අදහස ඔවුන්ට ඇත. Zalando ක්රියාකරු තුළ අපි මෑතකදී AWS වෙත සම්බන්ධතාවයක් දුටු බවත් මෙය තවදුරටත් හොඳ නැති බවත් මම දනිමි. නිශ්චිත යටිතල ව්‍යුහයකට බැඳීමක් නොතිබිය යුතුය - එසේ නම් එහි තේරුම කුමක්ද?
ඩී.එස්: මම හරියටම දන්නේ නැහැ Zalando කුමන තත්වයකට පත් වුනාද කියලා, නමුත් Kubernetes ගබඩාවේ දැන් සාමාන්ය ක්‍රමයක් භාවිතා කර තැටි උපස්ථයක් ගැනීමට නොහැකි වන ආකාරයට සාදා ඇත. මෑතකදී සම්මත - නවතම අනුවාදයේ - අපි ස්නැප්ෂොට් කළ හැකි නමුත් එය ක්රියාත්මක කරන්නේ කොතැනින්ද? අවන්කවම හැම දේම තාම අමු අමුවේ... අපි AWS, GCE, Azure, vSphere වලට උඩින් CSI ට්‍රයි කරනවා, එත් පාවිච්චි කරන්න පටන් ගත්ත ගමන්ම පේනවා ඇති ඒක තාම ලෑස්ති වෙලා නෑ කියලා.
НС: ඒ නිසා අපිට සමහර වෙලාවට යටිතල පහසුකම් මත විශ්වාසය තියන්න වෙනවා. මම හිතන්නේ මෙය තවමත් මුල් අවධියයි - වර්ධනය වන වේදනාව. ප්‍රශ්නය: K8s හි PgSQL උත්සාහ කිරීමට කැමති නවකයන්ට ඔබ දෙන උපදෙස් මොනවාද? සමහර විට කුමන ක්රියාකරුද?
ඩී.එස්: ප්‍රශ්නේ තියෙන්නේ Postgres අපිට 3%යි. අපි Kubernetes හි විවිධ මෘදුකාංගවල ඉතා විශාල ලැයිස්තුවක් ද ඇත, මම සියල්ල ලැයිස්තුගත නොකරමි. උදාහරණයක් ලෙස, Elasticsearch. බොහෝ ක්රියාකරුවන් ඇත: සමහරක් ක්රියාශීලීව සංවර්ධනය වෙමින් පවතී, අනෙක් අය එසේ නොවේ. අපට එය බැරෑරුම් ලෙස සැලකීම සඳහා ක්‍රියාකරුවෙකුට තිබිය යුතු දේ පිළිබඳව අප විසින්ම අවශ්‍යතා සකස් කර ඇත. විශේෂයෙන්ම Kubernetes සඳහා වූ ක්‍රියාකරුවෙකු තුළ - "Amazon කොන්දේසි යටතේ යමක් කිරීමට ක්රියාකරු" තුළ නොවේ... ඇත්ත වශයෙන්ම, අපි ඉතා පුළුල් ලෙස (= සියලුම ගනුදෙනුකරුවන් පාහේ) තනි ක්‍රියාකරුවෙකු භාවිතා කරමු - (අපි ඔහු ගැන ලිපියක් ළඟදීම පළ කරන්නෙමු).
НС: සහ MySQL සඳහා නොවේ ද? මම දන්නවා Percona... ඔවුන් දැන් MySQL, MongoDB, සහ Postgres මත වැඩ කරන බැවින්, ඔවුන්ට යම් ආකාරයක විශ්වීය විසඳුමක් නිර්මාණය කිරීමට සිදුවනු ඇත: සියලුම දත්ත සමුදායන් සඳහා, සියලුම වලාකුළු සපයන්නන් සඳහා.
ඩී.එස්: MySQL සඳහා ක්රියාකරුවන් දෙස බැලීමට අපට වෙලාවක් නොතිබුණි. දැනට අපගේ ප්රධාන අවධානය මෙය නොවේ. MySQL ස්වාධීනව හොඳින් ක්රියා කරයි. ඔබට දත්ත සමුදායක් දියත් කළ හැකි නම් ක්‍රියාකරුවෙකු භාවිතා කරන්නේ ඇයි... ඔබට Postrges සමඟ ඩොකර් කන්ටේනරයක් දියත් කළ හැකිය, නැතහොත් ඔබට එය සරල ආකාරයකින් දියත් කළ හැකිය.
НС: මේ ගැනත් ප්‍රශ්නයක් තිබුණා. ක්‍රියාකරුවෙක් නැද්ද?
ඩී.එස්: ඔව්, අපෙන් 100%කටම PostgreSQL ක්‍රියාකරුවෙකු නොමැතිව ක්රියාත්මක වේ. මෙතෙක් කල්. අපි Prometheus සහ Redis සඳහා ක්රියාකරු ක්රියාකාරීව භාවිතා කරමු. ප්‍රත්‍යාස්ථ සෙවීම සඳහා ක්‍රියාකරුවෙකු සොයා ගැනීමට අපට සැලසුම් තිබේ - එය වඩාත්ම “ගිනිගත්” එකයි, මන්ද අපට එය 100% කදී කුබර්නෙට්ස් හි ස්ථාපනය කිරීමට අවශ්ය බැවිනි. MongoDB සෑම විටම Kubernetes හි ස්ථාපනය කර ඇති බව සහතික කිරීමට අපට අවශ්ය සේම. මෙහිදී යම් යම් පැතුම් පෙනේ - මෙම අවස්ථා වලදී යමක් කළ හැකි බවට හැඟීමක් ඇත. අපි Postgres දෙස බැලුවේවත් නැත. ඇත්ත වශයෙන්ම, විවිධ විකල්ප ඇති බව අපි දනිමු, නමුත් ඇත්ත වශයෙන්ම අපට ස්වාධීන එකක් තිබේ.
Kubernetes හි පරීක්ෂණ සඳහා DB
НС: අපි පරීක්ෂණ මාතෘකාවට යමු. දත්ත සමුදායේ වෙනස්කම් සිදු කරන්නේ කෙසේද - DevOps ඉදිරිදර්ශනයකින්. ක්ෂුද්‍ර සේවා ඇත, බොහෝ දත්ත සමුදායන් ඇත, සෑම විටම කොහේ හරි යමක් වෙනස් වේ. DBMS ඉදිරිදර්ශනයෙන් සෑම දෙයක්ම පිළිවෙලට ඇති පරිදි සාමාන්ය CI/CD සහතික කරන්නේ කෙසේද. ඔබේ ප්රවේශය කුමක්ද?
ඩී.එස්: එක පිළිතුරක් තිබිය නොහැක. විකල්ප කිහිපයක් තිබේ. පළමුවැන්න නම් අපට පෙරළීමට අවශ්ය පදනමේ ප්‍රමාණයයි. ප්‍රොඩ් දත්ත සමුදායේ පිටපතක් dev සහ වේදිකාවේ තිබීම සම්බන්ධයෙන් සමාගම්වලට විවිධ ආකල්ප ඇති බව ඔබම සඳහන් කළා.
НС: ඒ වගේම GDPR හි කොන්දේසි යටතේ, මම හිතන්නේ ඔවුන් වැඩි වැඩියෙන් පරෙස්සම් වන බවයි ... යුරෝපයේ ඔවුන් දැනටමත් දඩ පැනවීමට පටන් ගෙන ඇති බව මට පැවසිය හැකිය.
ඩී.එස්: නමුත් බොහෝ විට ඔබට නිෂ්පාදනයෙන් ඩම්ප් එකක් ගෙන එය අපැහැදිලි කරන මෘදුකාංගයක් ලිවිය හැකිය. නිෂ්පාදන දත්ත ලබා ගනී (snapshot, dump, binary copy...), නමුත් එය නිර්නාමික කර ඇත. ඒ වෙනුවට, පරම්පරාවේ ස්ක්‍රිප්ට් තිබිය හැක: මේවා සවිකෘත හෝ විශාල දත්ත සමුදායක් ජනනය කරන ස්ක්‍රිප්ට් එකක් විය හැක. ගැටලුව වන්නේ: මූලික රූපයක් නිර්මාණය කිරීමට කොපමණ කාලයක් ගතවේද? සහ අපේක්ෂිත පරිසරය තුළ එය යෙදවීමට කොපමණ කාලයක් ගතවේද?
අපි යෝජනා ක්රමයකට පැමිණියෙමු: සේවාදායකයාට ස්ථාවර දත්ත කට්ටලයක් තිබේ නම් (දත්ත සමුදායේ අවම අනුවාදය), එවිට අපි ඒවා පෙරනිමියෙන් භාවිතා කරමු. අපි සමාලෝචන පරිසරයන් ගැන කතා කරන්නේ නම්, අපි ශාඛාවක් නිර්මාණය කරන විට, අපි යෙදුමේ උදාහරණයක් යෙදුවෙමු - අපි එහි කුඩා දත්ත ගබඩාවක් සකස් කරමු. නමුත් එය හොඳින් සිදු විය , අපි දිනකට වරක් (රාත්‍රියේ) නිෂ්පාදනයෙන් ඩම්ප් එකක් ගෙන එය මත පදනම්ව මෙම පැටවූ දත්ත සමඟ PostgreSQL සහ MySQL සමඟ ඩොකර් කන්ටේනරයක් සාදන විට. ඔබට මෙම රූපයෙන් දත්ත සමුදාය 50 වතාවක් පුළුල් කිරීමට අවශ්ය නම්, මෙය ඉතා සරලව හා ඉක්මනින් සිදු කෙරේ.
НС: සරල පිටපත් කිරීමෙන්?
ඩී.එස්: දත්ත සෘජුවම ඩොකර් රූපයේ ගබඩා කර ඇත. එම. 100 GB වුවද, අප සතුව සූදානම් කළ රූපයක් ඇත. Docker හි ඇති ස්ථර වලට ස්තූතියි, අපට මෙම රූපය අපට අවශ්ය වාර ගණනක් ඉක්මනින් යෙදවිය හැක. ක්රමය මෝඩයි, නමුත් එය හොඳින් ක්රියා කරයි.
НС: එතකොට ටෙස්ට් කරනකොට Docker එක ඇතුලෙ වෙනස් වෙනවා නේද? Docker එක ඇතුලේ Copy-on-write - ඒක විසි කරලා ආපහු යන්න, හැම දෙයක්ම හොඳයි. පන්තිය! ඔබ දැනටමත් එය උපරිමයෙන් භාවිතා කරනවාද?
ඩී.එස්: දිගු කාලයකට.
НС: අපි ගොඩක් සමාන දේවල් කරනවා. අපි පමණක් Docker's copy-on-write භාවිතා නොකරමු, නමුත් වෙනත් එකක්.
ඩී.එස්: එය පොදු නොවේ. ඒ වගේම Docker හැමතැනම වැඩ කරනවා.
НС: න්‍යායාත්මකව, ඔව්. නමුත් අපට එහි මොඩියුල ද ඇත, ඔබට විවිධ මොඩියුල සාදා විවිධ ගොනු පද්ධති සමඟ වැඩ කළ හැකිය. මෙහි මොනතරම් මොහොතක්ද. Postgres පැත්තෙන්, අපි මේ සියල්ල දෙස වෙනස් ලෙස බලන්නෙමු. දැන් මම Docker පැත්තෙන් බැලුවා, හැම දෙයක්ම ඔබට වැඩ කරනවා. නමුත් දත්ත සමුදාය විශාල නම්, උදාහරණයක් ලෙස, 1 TB, එවිට මේ සියල්ලට බොහෝ කාලයක් ගතවේ: රාත්‍රියේ මෙහෙයුම්, සහ සියල්ල Docker තුළට පුරවා ඇත ... සහ 5 TB ඩොකර් තුළට පුරවා ඇත්නම් ... නැතහොත් සියල්ල හොඳින් ද?
ඩී.එස්: වෙනස කුමක්ද: මේවා බ්ලොබ්, බිටු සහ බයිට් පමණි.
НС: වෙනස මෙයයි: ඔබ එය කරන්නේ ඩම්ප් සහ ප්‍රතිසාධනය හරහාද?
ඩී.එස්: කොහෙත්ම අවශ්ය නොවේ. මෙම රූපය උත්පාදනය කිරීමේ ක්රම වෙනස් විය හැකිය.
НС: සමහර සේවාලාභීන් සඳහා, අපි එය සාදා ඇති නිසා නිතිපතා මූලික රූපයක් ජනනය කරනවා වෙනුවට, අපි එය නිරන්තරයෙන් යාවත්කාලීනව තබා ගන්නෙමු. එය අත්‍යවශ්‍යයෙන්ම අනුරුවකි, නමුත් එයට දත්ත ලැබෙන්නේ ස්වාමියාගෙන් කෙලින්ම නොව ලේඛනාගාරයක් හරහාය. සෑම දිනකම WAL බාගත කරන, උපස්ථ ගන්නා ද්විමය සංරක්ෂිතයක්... මෙම WAL පසුව සුළු ප්‍රමාදයකින් (වචනාර්ථයෙන් තත්පර 1-2) මූලික රූපය වෙත ළඟා වේ. අපි එයින් ඕනෑම ආකාරයකින් ක්ලෝන කරමු - දැන් අපට පෙරනිමියෙන් ZFS ඇත.
ඩී.එස්: නමුත් ZFS සමඟ ඔබ එක් නෝඩයකට සීමා වේ.
НС: ඔව්. හැබැයි ZFS එකටත් මැජික් එකක් තියෙනවා : එය සමඟ ඔබට ස්නැප්ෂොට් එකක් යැවිය හැකි අතර (මම තවමත් මෙය පරීක්ෂා කර නැත, නමුත්...) ඔබට ඩෙල්ටා දෙකක් අතර යැවිය හැක. PGDATA. ඇත්ත වශයෙන්ම, එවැනි කාර්යයන් සඳහා අප සැබවින්ම නොසැලකූ තවත් මෙවලමක් අපට තිබේ. PostgreSQL සතුව ඇත , එය "ස්මාර්ට්" rsync ලෙස ක්රියා කරයි, ඔබ නැරඹිය යුතු නැති බොහෝ දේ මඟ හරියි, මන්ද එහි කිසිවක් වෙනස් වී නැත. අපිට සර්වර් දෙක අතර ඉක්මන් සමමුහුර්ත කිරීමක් කරලා ඒ විදියටම රිවයින්ඩ් කරන්න පුළුවන්.
ඉතින්, මෙයින්, තවත් DBA පැත්තෙන්, අපි ඔබ පැවසූ දෙයම කිරීමට ඉඩ සලසන මෙවලමක් නිර්මාණය කිරීමට උත්සාහ කරමු: අපට එක දත්ත සමුදායක් ඇත, නමුත් අපට යමක් එකවර 50 වතාවක් පරීක්ෂා කිරීමට අවශ්‍යයි.
ඩී.එස්: 50 වාරයක් යනු ඔබට ස්ථාන අවස්ථා 50ක් ඇණවුම් කිරීමට අවශ්ය වේ.
НС: නෑ, අපි හැම දෙයක්ම කරන්නේ එක යන්ත්‍රයකින්.
ඩී.එස්: නමුත් මෙම දත්ත සමුදාය ටෙරාබයිට් නම් ඔබ 50 ගුණයක් පුළුල් කරන්නේ කෙසේද? බොහෝ දුරට ඇයට කොන්දේසි සහිත 256 GB RAM එකක් අවශ්‍යද?
НС: ඔව්, සමහර විට ඔබට මතකය ගොඩක් අවශ්‍යයි - ඒක සාමාන්ය දෙයක්. නමුත් මෙය ජීවිතයෙන් ආදර්ශයකි. නිශ්පාදන යන්ත්රය 96 cores සහ 600 GB ඇත. ඒ සමගම, දත්ත සමුදාය සඳහා 32 core (දැන් සමහර විට cores 16ක් පවා) සහ 100-120 GB මතකයක් භාවිතා වේ.
ඩී.එස්: සහ පිටපත් 50 ක් එහි ගැලපේද?
НС: ඉතින් එක පිටපතක් විතරයි තියෙන්නේ, එතකොට copy-on-write (ZFS) වැඩ... මම ඔබට වඩාත් විස්තරාත්මකව කියන්නම්.
උදාහරණයක් ලෙස, අපට 10 TB දත්ත ගබඩාවක් ඇත. ඔවුන් ඒ සඳහා තැටියක් සාදන ලදී, ZFS ද එහි ප්‍රමාණය සියයට 30-40 කින් සම්පීඩනය කළේය. අපි පැටවුම් පරීක්ෂාව සිදු නොකරන බැවින්, නිශ්චිත ප්‍රතිචාර කාලය අපට වැදගත් නොවේ: එය 2 ගුණයක් දක්වා මන්දගාමී වීමට ඉඩ දෙන්න - එය කමක් නැත.
අපි ක්‍රමලේඛකයින්, QA, DBA යනාදිය සඳහා අවස්ථාව ලබා දෙමු. නූල් 1-2 කින් පරීක්ෂණ සිදු කරන්න. උදාහරණයක් ලෙස, ඔවුන් යම් ආකාරයක සංක්‍රමණයක් ක්රියාත්මක කළ හැකිය. එයට එකවර cores 10ක් අවශ්ය නොවේ - එයට Postgres backend 1ක්, core 1ක් අවශ්ය වේ. සංක්රමණය ආරම්භ වනු ඇත - සමහර විට තවමත් ආරම්භ වනු ඇත, පසුව දෙවන හරය භාවිතා කරනු ඇත. අපිට cores 16-32ක් වෙන් කරලා තියෙනවා, ඒ නිසා 10 දෙනෙකුට එකවර වැඩ කරන්න පුළුවන්, ප්‍රශ්නයක් නැහැ.
භෞතිකව නිසා PGDATA එසේම, අපි ඇත්ත වශයෙන්ම Postgres රවටා ඇති බව පෙනී යයි. උපක්‍රමය මෙයයි: උදාහරණයක් ලෙස, Postgres 10 ක් එකවර දියත් කෙරේ. සාමාන්යයෙන් ගැටලුව කුමක්ද? ඔවුන් තැබුවා , අපි 25% කියමු. ඒ අනුව මෙය 200 GB වේ. ඔබට මෙයින් තුනකට වඩා දියත් කිරීමට නොහැකි වනු ඇත, මන්ද මතකය අවසන් වනු ඇත.
නමුත් යම් අවස්ථාවක දී මෙය අවශ්ය නොවන බව අපට වැටහුණි: අපි share_buffers 2 GB ලෙස සකසා ඇත. PostgreSQL සතුව ඇත , සහ යථාර්ථයේ දී එය බලපාන්නේ එකම එකකි . අපි එය 0,5 TB ලෙස සකස් කරමු. ඒවා ඇත්ත වශයෙන්ම නොපවතින බව පවා කමක් නැත: ඔහු සැලසුම් කරන්නේ ඒවා පවතින ආකාරයට ය.
ඒ අනුව, අපි යම් ආකාරයක සංක්‍රමණයක් පරීක්ෂා කරන විට, අපට සියලු සැලසුම් එකතු කර ගත හැකිය - නිෂ්පාදනයේදී එය සිදුවන්නේ කෙසේදැයි අපි බලමු. එහි ඇති තත්පර වෙනස් (මන්දගාමී) වනු ඇත, නමුත් අප ඇත්ත වශයෙන්ම කියවන දත්ත සහ සැලසුම් (එහි සම්බන්ධ වන දේ, ආදිය) නිෂ්පාදනයේ දී මෙන් හරියටම සමාන වේ. තවද ඔබට එවැනි චෙක්පත් බොහොමයක් එක යන්ත්‍රයක සමාන්තරව ක්රියාත්මක කළ හැක.
ඩී.එස්: මෙතන ප්‍රශ්න ටිකක් තියෙනවා කියලා හිතෙන්නේ නැද්ද? පළමුවැන්න PostgreSQL මත පමණක් ක්රියා කරන විසඳුමකි. මෙම ප්රවේශය ඉතා පුද්ගලිකයි, එය සාමාන්ය නොවේ. දෙවැන්න නම්, Kubernetes (සහ වලාකුළු තාක්ෂණයන් දැන් යන සෑම දෙයක්ම) බොහෝ නෝඩ් වලට සම්බන්ධ වන අතර මෙම නෝඩ් තාවකාලික වේ. තවද ඔබගේ නඩුවේදී එය රාජ්යමය, ස්ථීර නෝඩයක් වේ. මේ දේවල් මාව ගැටුම් ඇති කරනවා.
НС: මුලින්ම, මම එකඟයි, මේක තනිකරම Postgres කතාවක්. මම හිතන්නේ අපි යම් ආකාරයක සෘජු IO සහ සියලුම මතකය සඳහා බෆර සංචිතයක් තිබේ නම්, මෙම ප්රවේශය ක්රියා නොකරනු ඇත - සැලසුම් වෙනස් වනු ඇත. නමුත් දැනට අපි වැඩ කරන්නේ Postgres සමඟ පමණි, අපි අන් අය ගැන සිතන්නේ නැත.
Kubernetes ගැන. අපට ස්ථිර දත්ත සමුදායක් ඇති බව ඔබම සෑම තැනකම අපට කියයි. අවස්ථාව අසමත් වුවහොත්, ප්රධාන දෙය වන්නේ තැටිය සුරැකීමයි. මෙන්න අපි Kubernetes හි සම්පූර්ණ වේදිකාව ද ඇති අතර, Postgres සමඟ ඇති සංරචකය වෙනම වේ (එය එක් දිනක් වුවද). එමනිසා, සෑම දෙයක්ම මේ වගේ ය: උදාහරණය පහත වැටුණි, නමුත් අපි එහි PV සුරකින ලද අතර එය කිසිවක් සිදු නොවූවාක් මෙන් එය වෙනත් (නව) අවස්ථාවකට සම්බන්ධ කළෙමු.
ඩී.එස්: මගේ දෘෂ්ටි කෝණයෙන්, අපි Kubernetes හි කරල් නිර්මාණය කරමු. K8s - elastic: knots අවශ්ය පරිදි ඇණවුම් කර ඇත. කාර්යය වන්නේ සරලව පොඩ් එකක් සාදා එයට X සම්පත් ප්‍රමාණයක් අවශ්ය බව පැවසීමයි, එවිට K8s එය තනිවම හඳුනා ගනී. නමුත් Kubernetes හි ගබඩා සහාය තවමත් අස්ථායී ය: ඇතුළත (මෙම නිකුතුව නිකුත් කරන ලදී සතියේ පෙර) මෙම විශේෂාංග බීටා පමණක් බවට පත් වේ.
මාස හයේ සිට අවුරුද්ද දක්වා ගත වනු ඇත - එය අඩු හෝ වැඩි වශයෙන් ස්ථාවර වනු ඇත, නැතහොත් අවම වශයෙන් එය ප්රකාශ කරනු ඇත. එවිට ස්නැප්ෂොට් සහ ප්‍රමාණය වෙනස් කිරීමේ හැකියාව ඔබේ ගැටලුව සම්පූර්ණයෙන්ම විසඳයි. මොකද ඔයාට පදනමක් තියෙනවා. ඔව්, එය ඉතා වේගවත් නොවිය හැක, නමුත් වේගය "හුඩ් යටතේ" ඇති දේ මත රඳා පවතී, සමහර ක්රියාත්මක කිරීම් තැටි උපපද්ධති මට්ටමින් පිටපත් කර පිටපත් කිරීමට සහ පිටපත් කිරීමට හැකි බැවිනි.
НС: සියලුම එන්ජින් (Amazon, Google...) සඳහා මෙම අනුවාදයට සහය දැක්වීම ආරම්භ කිරීමටද අවශ්ය වේ - මෙයටද යම් කාලයක් ගතවේ.
ඩී.එස්: අපි තවමත් ඒවා භාවිතා කරන්නේ නැහැ. අපි අපේ එක පාවිච්චි කරනවා.
Kubernetes සඳහා දේශීය සංවර්ධනය
НС: සියලුම කරල් එකම යන්ත්‍රයක සවිකර මෙතරම් කුඩා පරීක්ෂණයක් කිරීමට අවශ්ය වූ විට ඔබට එවැනි ප්‍රාර්ථනාවක් හමු වී තිබේද? සංකල්ප පිළිබඳ සාක්ෂි ඉක්මනින් ලබා ගැනීමට, ඒ සඳහා යන්ත්‍ර පොකුරක් කැප නොකර යෙදුම Kubernetes හි ධාවනය වන බව බලන්න. Minikube තියෙනවා නේද?
ඩී.එස්: මට පෙනෙන පරිදි මෙම නඩුව - එක් නෝඩයක් මත යොදවා ඇත - තනිකරම ප්‍රාදේශීය සංවර්ධනය ගැන. නැතහොත් එවැනි රටාවක සමහර ප්රකාශනයන්. කන්න , එහි පවතී , . අපි Kubernetes IN Docker භාවිතා කිරීමට ගමන් කරමින් සිටිමු. දැන් අපි පරීක්ෂණ සඳහා එය සමඟ වැඩ කිරීමට පටන් ගත්තා.
НС: මම කලින් හිතුවේ මේක එක Docker image එකක සියලුම Pods ඔතන්න කරපු උත්සහයක් කියලා. නමුත් මෙය සම්පූර්ණයෙන්ම වෙනස් දෙයක් ගැන බව පෙනී ගියේය. කොහොමත් වෙනම කන්ටේනර්, වෙනම පොඩ්ස් තියෙනවා - ඩොකර් එකේ විතරයි.
ඩී.එස්: ඔව්. තරමක් විහිලු අනුකරණයක් සිදු කර ඇත, නමුත් තේරුම මෙයයි ... අපට යෙදවීම සඳහා උපයෝගීතාවයක් ඇත - . අපට එය කොන්දේසි සහිත මාදිලියක් බවට පත් කිරීමට අවශ්‍යයි werf up: "මට දේශීය කුබර්නෙට්ස් ලබා දෙන්න." ඉන්පසු එහි කොන්දේසිය ධාවනය කරන්න werf follow. එවිට සංවර්ධකයාට IDE සංස්කරණය කිරීමට හැකි වනු ඇති අතර, වෙනස්කම් දකින සහ රූප නැවත ගොඩනඟා, ඒවා දේශීය K8 වෙත නැවත යෙදවීම සඳහා ක්‍රියාවලියක් පද්ධතිය තුළ දියත් කෙරේ. ප්‍රාදේශීය සංවර්ධනය පිළිබඳ ප්‍රශ්නය විසඳීමට අපි උත්සාහ කරන්නේ එලෙස ය.
K8s යථාර්ථය තුළ ස්නැප්ෂොට් සහ දත්ත සමුදා ක්ලෝනකරණය
НС: අපි copy-on-write වෙත ආපසු ගියහොත්. වලාකුළු වල ස්නැප්ෂොට් ද ඇති බව මම දුටුවෙමි. ඔවුන් වෙනස් ලෙස ක්රියා කරයි. උදාහරණයක් ලෙස, GCP හි: ඔබට එක්සත් ජනපදයේ නැගෙනහිර වෙරළ තීරයේ බහු-ටෙරාබයිට් අවස්ථාවක් තිබේ. ඔබ වරින් වර ඡායාරූප ගන්නවා. ඔබ බටහිර වෙරළ තීරයේ තැටියේ පිටපතක් ස්නැප්ෂොට් එකකින් ලබා ගනී - මිනිත්තු කිහිපයකින් සියල්ල සූදානම්, එය ඉතා ඉක්මනින් ක්රියා කරයි, හැඹිලිය පමණක් මතකයෙන් පිරවිය යුතුය. නමුත් මෙම ක්ලෝන (snapshots) නව පරිමාවක් 'ප්‍රතිපාදන' කිරීම සඳහා වේ. ඔබට බොහෝ අවස්ථාවන් නිර්මාණය කිරීමට අවශ්ය විට මෙය සිසිල් ය.
නමුත් පරීක්ෂණ සඳහා, ඔබ Docker හි කතා කරන හෝ මම ZFS, btrfs සහ LVM වල පවා කතා කරන ස්නැප්ෂොට් ... - ඒවා ඔබට එක යන්ත්‍රයක සැබවින්ම නව දත්ත නිර්මාණය නොකිරීමට ඉඩ දෙයි. වලාකුළෙහි, ඔබ තවමත් සෑම අවස්ථාවකම ඔවුන් සඳහා ගෙවනු ඇති අතර තත්පර නොව මිනිත්තු (සහ නඩුවේදී) රැඳී සිටින්න , සමහරවිට ඔරලෝසුවක්).
ඒ වෙනුවට, ඔබට තත්පරයකින් හෝ දෙකකින් මෙම දත්ත ලබා ගත හැකිය, පරීක්ෂණය ධාවනය කර එය විසි කරන්න. මෙම ස්නැප්ෂොට් විවිධ ගැටලු විසඳයි. පළමු අවස්ථාවේ දී - පරිමාණය කිරීමට සහ නව අනුරූ ලබා ගැනීමට, සහ දෙවන - පරීක්ෂණ සඳහා.
ඩී.එස්: මම එකඟ නැහැ. පරිමා ක්ලෝන කිරීම නිසියාකාරව ක්රියාත්මක කිරීම වලාකුළෙහි කාර්යයයි. මම ඒවා ක්රියාත්මක කිරීම දෙස බැලුවේ නැත, නමුත් දෘඩාංග මත අපි එය කරන්නේ කෙසේදැයි මම දනිමි. අපට සීෆ් ඇත, එය ඕනෑම භෞතික පරිමාවකට ඉඩ දෙයි () කියන්න ක්ලෝන සහ මිලි තත්පර දස ගණනකින් එකම ලක්ෂණ සහිත දෙවන වෙළුමක් ලබා ගන්න, 'අමි, ආදිය. ඔබ තේරුම් ගත යුතු වන්නේ ඇතුලේ කපටි කොපි-ඔන්-රයිට් එකක් තිබෙන බවයි. වලාකුළත් එසේ නොකළ යුත්තේ ඇයි? ඔවුන් මෙය එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් කිරීමට උත්සාහ කරන බව මට විශ්වාසයි.
НС: නමුත් ඔවුන්ට තත්ත්පර, තත්පර දස ගනනක් ගත වනු ඇත, උදාහරණයක් මතු කිරීමට, ඩොකර් එහි ගෙන ඒමට යනාදිය.
ඩී.එස්: සම්පූර්ණ අවස්ථාවක් මතු කිරීමට අවශ්ය වන්නේ ඇයි? අපට මධ්‍ය 32 ක් සහිත උදාහරණයක් ඇත, 16 ... එය එයට ගැලපේ - උදාහරණයක් ලෙස, හතරක්. අපි පස්වන එක ඇණවුම් කරන විට, උදාහරණය දැනටමත් ඉහළ නංවනු ඇත, පසුව එය මකා දැමෙනු ඇත.
НС: ඔව්, රසවත්, Kubernetes වෙනස් කතාවක් බවට පත් වෙයි. අපගේ දත්ත සමුදාය K8s හි නොමැති අතර අපට එක් අවස්ථාවක් තිබේ. නමුත් බහු ටෙරාබයිට් දත්ත සමුදායක් ක්ලෝන කිරීම තත්පර දෙකකට වඩා ගත නොවේ.
ඩී.එස්: මේක නියමයි. නමුත් මගේ මූලික අදහස නම් මෙය සාමාන්ය විසඳුමක් නොවන බවයි. ඔව්, එය සිසිල් ය, නමුත් එය Postgres සඳහා පමණක් සුදුසු වන අතර එක් නෝඩයක් මත පමණි.
НС: එය Postgres සඳහා පමණක් සුදුසු නොවේ: මෙම සැලසුම්, මා විස්තර කළ පරිදි, එය තුළ පමණක් ක්රියා කරනු ඇත. නමුත් අපි සැලසුම් ගැන කරදර නොවන්නේ නම් සහ අපට ක්‍රියාකාරී පරීක්ෂණ සඳහා සියලු දත්ත අවශ්ය නම්, මෙය ඕනෑම DBMS සඳහා සුදුසු වේ.
ඩී.එස්: වසර ගණනාවකට පෙර අපි LVM ස්නැප්ෂොට් මත සමාන දෙයක් කළා. මෙය සම්භාව්යයකි. මෙම ප්රවේශය ඉතා ක්රියාශීලීව භාවිතා කරන ලදී. රාජ්ය නෝඩ් වේදනාවක් පමණි. ඔබ ඔවුන්ව අත් නොහැරිය යුතු නිසා, ඔබ ඒවා නිතරම මතක තබා ගත යුතුය.
НС: ඔබට මෙහි දෙමුහුන් වර්ගයක හැකියාවක් පෙනෙනවාද? අපි කියමු stateful යනු යම් ආකාරයක පොඩ් වර්ගයකි, එය කිහිප දෙනෙකුට (බොහෝ පරීක්ෂකයින්) ක්රියා කරයි. අපට එක් වෙළුමක් ඇත, නමුත් ගොනු පද්ධතියට ස්තූතියි, ක්ලෝන දේශීය වේ. පොඩ් එක වැටුණත් තැටිය ඉතිරිව තිබේ නම්, පොඩ් එක ඉහළ යනු ඇත, සියලුම ක්ලෝන පිළිබඳ තොරතුරු ගණන් කරන්න, සියල්ල නැවත ලබාගෙන මෙසේ කියන්න: “මෙන්න ඔබේ ක්ලෝන මෙම වරායන් මත ක්රියාත්මක වේ, ඒවා සමඟ දිගටම වැඩ කරන්න.”
ඩී.එස්: තාක්ෂණික වශයෙන් මෙයින් අදහස් කරන්නේ Kubernetes තුළ එය අපි බොහෝ Postgres ධාවනය කරන එක් පොඩ් එකක් බවයි.
НС: ඔව්. ඔහුට සීමාවක් තිබේ: ඔහු සමඟ එකවර 10 දෙනෙකුට වඩා වැඩ නොකරන බව කියමු. ඔබට 20 ක් අවශ්ය නම්, අපි එවැනි දෙවන පොඩ් එකක් දියත් කරන්නෙමු. අපි එය සම්පූර්ණයෙන්ම ක්ලෝන කරන්නෙමු, දෙවන සම්පූර්ණ වෙළුම ලැබුණු පසු, එයට එකම “තුනී” ක්ලෝන 10 ක් ඇත. ඔබට මේ අවස්ථාව පෙනෙන්නේ නැද්ද?
ඩී.එස්: අපි මෙහි ආරක්ෂක ගැටළු එකතු කළ යුතුයි. මෙම වර්ගයේ සංවිධානයෙන් ඇඟවෙන්නේ මෙම පොඩ්ට ඉහළ වරප්‍රසාද (හැකියාවන්) ඇති බවයි, මන්ද එයට ගොනු පද්ධතියේ සම්මත නොවන මෙහෙයුම් සිදු කළ හැකි බැවිනි... නමුත් මම නැවත කියමි: මධ්‍ය කාලීනව ඔවුන් Kubernetes හි ගබඩාව සවි කරනු ඇතැයි මම විශ්වාස කරමි. වලාකුළු ඔවුන් මුළු කතාවම වෙළුම් වලින් සවි කරනු ඇත - සෑම දෙයක්ම "ක්රියාත්මක වනු ඇත". ප්‍රමාණය වෙනස් කිරීම, ක්ලෝන කිරීම ... පරිමාවක් ඇත - අපි කියන්නේ: "ඒ මත පදනම්ව නව එකක් සාදන්න," සහ තත්පර එකහමාරකට පසු අපට අවශ්ය දේ ලැබේ.
НС: මම බොහෝ ටෙරාබයිට් සඳහා තත්පර එකහමාරක් විශ්වාස නොකරමි. Cep හි ඔබ එය ඔබම කරයි, නමුත් ඔබ වලාකුළු ගැන කතා කරයි. වලාකුළට ගොස්, EC2 මත බහු-ටෙරාබයිට් EBS පරිමාවක ක්ලෝනයක් සාදා කාර්ය සාධනය කුමක්දැයි බලන්න. තත්පර කිහිපයක් ගත නොවනු ඇත. ඔවුන් මේ මට්ටමට ළඟා වන්නේ කවදාද යන්න ගැන මම ඉතා උනන්දු වෙමි. ඔබ කියන දේ මට තේරෙනවා, නමුත් මම වෙනස් වන ලෙස ඉල්ලා සිටිමි.
ඩී.එස්: හරි හැබැයි මම කිව්වේ මධ්‍යම කාලීනව මිසක් කෙටි කාලීනව නෙවෙයි. වසර ගණනාවක් තිස්සේ.
Zalando වෙතින් PostgreSQL සඳහා ක්රියාකරු ගැන
මෙම රැස්වීම මැද, Zalando හි හිටපු සංවර්ධකයෙකු වන Alexey Klyukin ද සම්බන්ධ වී PostgreSQL ක්‍රියාකරුගේ ඉතිහාසය ගැන කතා කළේය:
මෙම මාතෘකාව පොදුවේ ස්පර්ශ කිරීම ඉතා හොඳයි: Postgres සහ Kubernetes යන දෙකම. අපි 2017 දී Zalando හි එය කිරීමට පටන් ගත් විට, එය සෑම කෙනෙකුටම කිරීමට අවශ්ය මාතෘකාවක් විය, නමුත් කිසිවෙකු එය කළේ නැත. සෑම කෙනෙකුටම දැනටමත් Kubernetes ඇත, නමුත් ඔවුන් දත්ත සමුදායන් සමඟ කළ යුත්තේ කුමක්දැයි විමසූ විට, මිනිසුන් පවා කැමතියි , K8s දේශනා කළ, මේ වගේ දෙයක් කිව්වා:
"කළමනාකරණය කළ සේවාවන් වෙත ගොස් ඒවා භාවිතා කරන්න, Kubernetes හි දත්ත සමුදාය ධාවනය නොකරන්න. එසේ නොමැතිනම්, ඔබගේ K8s තීරණය කරනු ඇත, උදාහරණයක් ලෙස, උත්ශ්‍රේණිගත කිරීමක් කිරීමට, සියලුම නෝඩ් ක්රියා විරහිත කරන්න, සහ ඔබගේ දත්ත බොහෝ ඈතට පියාසර කරනු ඇත.
මෙම උපදෙසට පටහැනිව, Kubernetes හි Postgres දත්ත ගබඩාවක් දියත් කරන ක්‍රියාකරුවෙකු සෑදීමට අපි තීරණය කළෙමු. අපිට හොඳ හේතුවක් තිබුණා - . මෙය PostgreSQL සඳහා ස්වයංක්‍රීය අසමත් වීමකි, නිවැරදිව සිදු කර ඇත, i.e. පොකුර පිළිබඳ තොරතුරු ගබඩාවක් ලෙස etcd, කොන්සල් හෝ ZooKeeper භාවිතා කිරීම. අසන සෑම කෙනෙකුටම ලබා දෙන එවැනි ගබඩාවක්, උදාහරණයක් ලෙස, වත්මන් නායකයා යනු කුමක්ද, එකම තොරතුරු - අප සතුව සෑම දෙයක්ම බෙදා හැර ඇතත් - මොළය බෙදීමක් සිදු නොවේ. ඊට අමතරව අපිට තිබුණා ඔහු වෙනුවෙන්.
සාමාන්යයෙන්, අභ්‍යන්තර දෘඩාංග දත්ත මධ්‍යස්ථානයකින් වලාකුළට සංක්රමණය වීමෙන් පසු ස්වයංක්‍රීයව අසමත් වීම සඳහා සමාගමේ අවශ්‍යතාවය දිස් විය. වලාකුළු හිමිකාර PaaS (Platform-as-a-Service) විසඳුමක් මත පදනම් විය. එය විවෘත මූලාශ්‍රයක්, නමුත් එය ක්රියාත්මක කිරීමට විශාල වෙහෙසක් දැරීමට සිදු විය. එය හැඳින්වූයේය .
මුලදී, Kubernetes සිටියේ නැත. වඩාත් නිවැරදිව, අපගේම විසඳුමක් යොදවා ඇති විට, K8s දැනටමත් පැවතුනි, නමුත් එය නිෂ්පාදනය සඳහා සුදුසු නොවන බව ඉතා රළු විය. එය මගේ මතය අනුව 2015 හෝ 2016 විය. 2017 වන විට, Kubernetes අඩු වැඩි වශයෙන් පරිණත වී ඇත - එහි සංක්රමණය වීමට අවශ්ය විය.
ඒ වගේම අපිට දැනටමත් Docker කන්ටේනරයක් තිබුණා. Docker පාවිච්චි කරපු PaaS එකක් තිබුණා. K8s උත්සාහ නොකරන්නේ ඇයි? ඔබේම ක්රියාකරු ලියන්නේ නැත්තේ ඇයි? Avito සිට අප වෙත පැමිණි මුරාත් කබිලොව් මෙය ඔහුගේම මූලිකත්වයෙන් ව්‍යාපෘතියක් ලෙස ආරම්භ කළේය - "සෙල්ලම් කිරීමට" - සහ ව්‍යාපෘතිය "ආරම්භ විය."
නමුත් පොදුවේ, මට AWS ගැන කතා කිරීමට අවශ්ය විය. ඓතිහාසික AWS සම්බන්ධ කේතයක් තිබුනේ ඇයි...
ඔබ Kubernetes හි යමක් ධාවනය කරන විට, K8s යනු ක්රියාත්මක වෙමින් පවතින කාර්යයක් බව ඔබ තේරුම් ගත යුතුය. එය නිරන්තරයෙන් වර්ධනය වෙමින්, වැඩිදියුණු වෙමින් සහ කලින් කලට බිඳ වැටෙමින් පවතී. ඔබ Kubernetes හි ඇති සියලුම වෙනස්කම් පිළිබඳව හොඳින් විමසිල්ලෙන් සිටිය යුතුය, යමක් සිදුවුවහොත් ඔබ එයට කිමිදීමට සූදානම් විය යුතු අතර එය ක්රියා කරන ආකාරය විස්තරාත්මකව ඉගෙන ගත යුතුය - සමහර විට ඔබ කැමති දේට වඩා. මෙය, ප්‍රතිපත්තිමය වශයෙන්, ඔබ ඔබේ දත්ත සමුදායන් ක්රියාත්මක කරන ඕනෑම වේදිකාවකට අදාළ වේ...
ඉතින්, අපි ප්‍රකාශය කළ විට, අපට Postgres බාහිර පරිමාවක් මත ක්රියාත්මක විය (මෙම අවස්ථාවෙහි EBS, අපි AWS මත වැඩ කරමින් සිටි බැවින්). දත්ත සමුදාය වර්ධනය විය, යම් අවස්ථාවක එය ප්‍රමාණය වෙනස් කිරීමට අවශ්ය විය: උදාහරණයක් ලෙස, EBS හි ආරම්භක ප්‍රමාණය 100 TB විය, දත්ත සමුදාය එය දක්වා වර්ධනය විය, දැන් අපට EBS 200 TB කිරීමට අවශ්‍යයි. කෙසේද? ඔබට නව අවස්ථාවක ඩම්ප්/ප්‍රතිසාධනය කළ හැකි යැයි සිතමු, නමුත් මෙයට බොහෝ කාලයක් ගත වන අතර අක්‍රිය කාලයක් ඇතුළත් වේ.
එම නිසා, මට EBS කොටස විශාල කර නව ඉඩ භාවිතා කරන ලෙස ගොනු පද්ධතියට පවසන ප්‍රමාණය වෙනස් කිරීමට අවශ්ය විය. අපි එය කළෙමු, නමුත් එම අවස්ථාවේ Kubernetes හට ප්‍රමාණය වෙනස් කිරීමේ මෙහෙයුම සඳහා API කිසිවක් නොතිබුණි. අපි AWS මත වැඩ කළ නිසා, අපි එහි API සඳහා කේතය ලිව්වෙමු.
වෙනත් වේදිකා සඳහාද එසේ කිරීමෙන් කිසිවෙකු ඔබව වළක්වන්නේ නැත. එය AWS මත පමණක් ක්රියාත්මක කළ හැකි බවට ප්‍රකාශයේ කිසිදු ඉඟියක් නොමැති අතර එය අනෙක් සියල්ල මත ක්රියා නොකරනු ඇත. පොදුවේ ගත් කල, මෙය විවෘත මූලාශ්‍ර ව්‍යාපෘතියකි: නව API භාවිතයේ මතුවීම වේගවත් කිරීමට යමෙකුට අවශ්ය නම්, ඔබව සාදරයෙන් පිළිගනිමු. කන්න , ඉල්ලීම් අදින්න - Zalando කණ්ඩායම ඉතා ඉක්මනින් ඒවාට ප්‍රතිචාර දැක්වීමට සහ ක්රියාකරු ප්‍රවර්ධනය කිරීමට උත්සාහ කරයි. මම දන්නා තරමින් ව්‍යාපෘතිය Google Summer of Code සහ වෙනත් සමාන මුල පිරීම් වල. Zalando ඒ සඳහා ඉතා ක්රියාශීලීව කටයුතු කරයි.
PS බෝනස්!
ඔබ PostgreSQL සහ Kubernetes මාතෘකාව ගැන උනන්දුවක් දක්වන්නේ නම්, ඊළඟ Postgres අඟහරුවාදා මම නිකොලායි සමඟ කතා කළ සතියේ සිදු වූ බව කරුණාවෙන් සලකන්න. Zalando සිට ඇලෙක්සැන්ඩර් කුකුෂ්කින්. එහි වීඩියෝව තිබේ .
පීපීඑස්
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «»;
- «»;
- «»;
- «".
මූලාශ්රය: www.habr.com