"ነጻ" PostgreSQLን ወደ ከባድ የድርጅት አካባቢ እንዴት እንደሚገጥም

ብዙ ሰዎች ከ PostgreSQL DBMS ጋር በደንብ ያውቃሉ፣ እና እራሱን በትናንሽ ጭነቶች አረጋግጧል። ይሁን እንጂ ከትላልቅ ኩባንያዎች እና የድርጅት መስፈርቶች ጋር በተያያዘ እንኳን ወደ ክፍት ምንጭ ያለው አዝማሚያ ግልጽ እየሆነ መጥቷል. በዚህ ጽሑፍ ውስጥ Postgresን ወደ የድርጅት አካባቢ እንዴት እንደሚዋሃዱ እናነግርዎታለን እና Commvault የመጠባበቂያ ስርዓትን እንደ ምሳሌ በመጠቀም ለዚህ የውሂብ ጎታ የመጠባበቂያ ስርዓት (BSS) የመፍጠር ልምዳችንን እናካፍላለን።

PostgreSQL ዋጋውን አስቀድሞ አረጋግጧል - ዲቢኤምኤስ በጣም ጥሩ ይሰራል፣ እንደ አሊባባ እና ትራይፕአድቪሰር ባሉ ፋሽን ዲጂታል ንግዶች ጥቅም ላይ ይውላል፣ እና የፍቃድ ክፍያ አለመኖር እንደ MS SQL ወይም Oracle DB ካሉ ጭራቆች አጓጊ አማራጭ ያደርገዋል። ግን በድርጅት መልክዓ ምድር ውስጥ ስለ PostgreSQL ማሰብ እንደጀመርን ወዲያውኑ ወደ ጥብቅ መስፈርቶች እንገባለን፡ “ስለ የውቅር ስህተት መቻቻልስ? የአደጋ መቋቋም? አጠቃላይ ክትትል የት ነው ያለው? ስለ አውቶማቲክ ምትኬዎችስ? የቴፕ ቤተ-መጻሕፍትን በቀጥታም ሆነ በሁለተኛ ደረጃ ማከማቻ ላይ ስለመጠቀምስ?


በአንድ በኩል፣ PostgreSQL አብሮ የተሰሩ የመጠባበቂያ መሳሪያዎች የሉትም፣ እንደ “አዋቂ” ዲቢኤምኤስ እንደ RMAN በ Oracle DB ወይም SAP Database Backup። በሌላ በኩል የኮርፖሬት መጠባበቂያ ሲስተሞች (Veeam, Veritas, Commvault) አቅራቢዎች PostgreSQL ን ቢደግፉም ግን ከተወሰነ (በተለምዶ ገለልተኛ) ውቅር እና ከተለያዩ ገደቦች ጋር ብቻ ይሰራሉ።

እንደ ባርማን፣ ዋል-ጂ፣ ፒጂ_ፕሮባክአፕ፣ በልዩ ሁኔታ ለ PostgreSQL የተነደፉ የመጠባበቂያ ሲስተሞች፣ በPostgreSQL DBMS ትንንሽ ጭነቶች ውስጥ ወይም የሌሎች የአይቲ መልከዓ ምድር ክፍሎች ከባድ መጠባበቂያዎች አያስፈልጉም። ለምሳሌ ከPostgreSQL በተጨማሪ መሠረተ ልማቱ አካላዊ እና ምናባዊ አገልጋዮችን፣ OpenShift፣ Oracle፣ MariaDB፣ Cassandra፣ ወዘተ ሊያካትት ይችላል። ይህንን ሁሉ በጋራ መገልገያ መደገፍ ይመረጣል. ለ PostgreSQL ብቻ የተለየ መፍትሄ መጫን መጥፎ ሀሳብ ነው፡ ውሂቡ የሆነ ቦታ ወደ ዲስክ ይገለበጣል እና ከዚያ በቴፕ መወገድ አለበት። ይህ ድርብ ምትኬ የመጠባበቂያ ጊዜን ይጨምራል፣ እና ደግሞ፣ ይበልጥ ወሳኝ፣ የመልሶ ማግኛ ጊዜ።

በድርጅት መፍትሄ ውስጥ ፣ የመጫኑ ምትኬ በተወሰነ ስብስብ ውስጥ በተወሰኑ የአንጓዎች ብዛት ይከሰታል። በተመሳሳይ ጊዜ, ለምሳሌ, Commvault በሁለት-ኖድ ክላስተር ብቻ ሊሰራ ይችላል, በዚህ ውስጥ የመጀመሪያ ደረጃ እና ሁለተኛ ደረጃ ለተወሰኑ አንጓዎች በጥብቅ ይመደባሉ. እና ከመጀመሪያ ደረጃ ምትኬን ማድረጉ ብቻ ትርጉም ይሰጣል ፣ ምክንያቱም የሁለተኛ ደረጃ ምትኬ ገደቦች አሉት። በዲቢኤምኤስ ልዩነት ምክንያት, ቆሻሻ ማጠራቀሚያ በሁለተኛ ደረጃ ላይ አልተፈጠረም, እና ስለዚህ የፋይል ምትኬን የመጠቀም እድል ብቻ ይቀራል.

የመዘግየት አደጋን ለመቀነስ ስህተትን የሚቋቋም ስርዓት ሲፈጥሩ "ቀጥታ" ክላስተር ውቅር ይፈጠራል እና ፕሪምሪ ቀስ በቀስ በተለያዩ አገልጋዮች መካከል ሊፈልስ ይችላል። ለምሳሌ፣ Patroni ሶፍትዌር ራሱ በዘፈቀደ በተመረጠ የክላስተር መስቀለኛ መንገድ ቀዳሚን ይጀምራል። IBS ይህንን ከሳጥኑ ውስጥ ለመከታተል ምንም መንገድ የለውም, እና አወቃቀሩ ከተቀየረ, ሂደቶቹ ይቋረጣሉ. ማለትም የውጭ መቆጣጠሪያን ማስተዋወቅ ISR ውጤታማ በሆነ መንገድ እንዳይሰራ ይከለክላል, ምክንያቱም የቁጥጥር አገልጋዩ በቀላሉ ከየት እና ከየትኛው ውሂብ መቅዳት እንዳለበት አይረዳም.

ሌላው ችግር በ Postgres ውስጥ የመጠባበቂያ ትግበራ ነው. በቆሻሻ ማጠራቀሚያ በኩል ይቻላል, እና በትንሽ የውሂብ ጎታዎች ላይ ይሰራል. ነገር ግን በትልቅ የውሂብ ጎታዎች ውስጥ, ቆሻሻው ረጅም ጊዜ ይወስዳል, ብዙ ሀብቶችን ይፈልጋል እና የውሂብ ጎታውን ምሳሌ ወደ ውድቀት ሊያመራ ይችላል.

የፋይል መጠባበቂያ ሁኔታውን ያስተካክላል, ነገር ግን በትልልቅ የውሂብ ጎታዎች ላይ ቀርፋፋ ነው ምክንያቱም በነጠላ ክር ሁነታ ይሰራል. በተጨማሪም, ሻጮች በርካታ ተጨማሪ ገደቦች አሏቸው. ፋይልን መጠቀም እና ምትኬዎችን በተመሳሳይ ጊዜ መጣል አይችሉም ወይም መቀነስ አይደገፍም። ብዙ ችግሮች አሉ፣ እና ብዙ ጊዜ ከፖስትግሬስ ይልቅ ውድ ግን የተረጋገጠ DBMS መምረጥ ቀላል ነው።

ማፈግፈግ የትም የለም! የሞስኮ ገንቢዎች ከኋላ ናቸው!

ይሁን እንጂ በቅርቡ ቡድናችን አስቸጋሪ ፈተና አጋጥሞታል፡ በፕሮጀክቱ ውስጥ AIS OSAGO 2.0 ን ለመፍጠር, የአይቲ መሠረተ ልማትን በፈጠርንበት, ገንቢዎቹ PostgreSQL ለአዲሱ ስርዓት መርጠዋል.

ለትልቅ የሶፍትዌር ገንቢዎች "ወቅታዊ" ክፍት ምንጭ መፍትሄዎችን መጠቀም በጣም ቀላል ነው። ፌስቡክ የዚህን ዲቢኤምኤስ አሰራር ለመደገፍ በቂ ልዩ ባለሙያዎች አሉት። እና በ RSA ሁኔታ, የ "ሁለተኛው ቀን" ተግባራት በሙሉ በትከሻችን ላይ ወድቀዋል. ስህተት መቻቻልን ማረጋገጥ፣ ዘለላ ማሰባሰብ እና በእርግጥ ምትኬን ማዘጋጀት ነበረብን። የተግባር አመክንዮ የሚከተለው ነበር።

• SRK ከክላስተር ዋና መስቀለኛ መንገድ ምትኬዎችን እንዲሰራ አስተምሩት። ይህንን ለማድረግ SRK ማግኘት አለበት - ይህ ማለት ከአንድ ወይም ከሌላ የ PostgreSQL ክላስተር አስተዳደር መፍትሄ ጋር መቀላቀል ያስፈልጋል። በ RSA ጉዳይ, Patroni ሶፍትዌር ለዚህ ጥቅም ላይ ውሏል.
• በመረጃ ብዛት እና በመልሶ ማግኛ መስፈርቶች ላይ በመመስረት የመጠባበቂያውን አይነት ይወስኑ። ለምሳሌ ገጾቹን በጥራጥሬ ወደነበረበት መመለስ ሲፈልጉ ቆሻሻን ይጠቀሙ እና የውሂብ ጎታዎቹ ትልቅ ከሆኑ እና የጥራጥሬ እድሳት የማያስፈልግ ከሆነ በፋይል ደረጃ ይስሩ።
• በባለብዙ ክር ሁነታ የመጠባበቂያ ቅጂ ለመፍጠር የመጠባበቂያ ቅጂን ወደ መፍትሄ የማገድ እድልን ያያይዙ.

በተመሳሳይ ጊዜ, እኛ መጀመሪያ ላይ ተጨማሪ አካላት ያለ ጭራቅ መታጠቂያ ውጤታማ እና ቀላል ሥርዓት ለመፍጠር ተነሳ. ጥቂቶቹ ክራንች፣ የሰራተኞች የስራ ጫና ይቀንሳል እና የIBS ውድቀት ስጋት ይቀንሳል። ወዲያውኑ Veeam እና RMAN የተጠቀሙ አቀራረቦችን አስቀርተናል፣ ምክንያቱም የሁለት መፍትሄዎች ስብስብ የስርዓቱን አስተማማኝነት አስቀድሞ ይጠቁማል።

ለድርጅት ትንሽ አስማት

ስለዚህ፣ ለ10 ዘለላዎች እያንዳንዳቸው 3 አንጓዎች፣ ተመሳሳይ መሠረተ ልማቶች በመጠባበቂያ ዳታ ማዕከሉ ውስጥ የተንፀባረቁበት አስተማማኝ መጠባበቂያ ዋስትና መስጠት አለብን። የውሂብ ማእከሎች ከ PostgreSQL አንፃር በንቃት-ተሳቢ መርህ ላይ ይሰራሉ። አጠቃላይ የመረጃ ቋቱ መጠን 50 ቴባ ነበር። ማንኛውም የድርጅት ደረጃ ቁጥጥር ስርዓት ይህንን በቀላሉ መቋቋም ይችላል። ነገር ግን ማስጠንቀቂያው መጀመሪያ ላይ Postgres ከመጠባበቂያ ስርዓቶች ጋር ሙሉ እና ጥልቅ ተኳሃኝነትን በተመለከተ ፍንጭ የለውም. ስለዚህ, ከ PostgreSQL ጋር በመተባበር መጀመሪያ ላይ ከፍተኛ ተግባር ያለው መፍትሄ መፈለግ እና ስርዓቱን ማጣራት ነበረብን.

3 ውስጣዊ “hackathons”ን ያዝን - ከሃምሳ በላይ እድገቶችን ተመልክተናል፣ ፈትነናቸው፣ ከመላምቶቻችን ጋር በተያያዘ ለውጦችን አድርገናል እና እንደገና ሞከርናቸው። ያሉትን አማራጮች ከገመገምን በኋላ, Commvault ን መርጠናል. ከሳጥኑ ውስጥ፣ ይህ ምርት በጣም ቀላል ከሆነው የ PostgreSQL ክላስተር ጭነት ጋር ሊሰራ ይችላል፣ እና ክፍት አርክቴክቸር ለስኬታማ ልማት እና ውህደት ተስፋን ከፍቷል (የተረጋገጠ)። Commvault የPostgreSQL ምዝግብ ማስታወሻዎችን ምትኬ ማድረግ ይችላል። ለምሳሌ፣ Veritas NetBackup ከPostgreSQL አንፃር ሙሉ ምትኬዎችን ብቻ መስራት ይችላል።

ስለ አርክቴክቸር ተጨማሪ። Commvault አስተዳደር አገልጋዮች በCommServ HA ውቅር ውስጥ በእያንዳንዱ ሁለቱ የመረጃ ማዕከላት ውስጥ ተጭነዋል። ስርዓቱ ተንጸባርቋል፣ በአንድ ኮንሶል የሚተዳደር እና፣ ከ HA እይታ አንጻር፣ ሁሉንም የድርጅት መስፈርቶች ያሟላል።

በተጨማሪም በእያንዳንዱ የመረጃ ማዕከል ውስጥ ሁለት አካላዊ ሚዲያ ሰርቨሮችን አስከፈትን፤ ለዚህም የዲስክ ድርድር እና የቴፕ ቤተ-መጻሕፍትን በ SAN በኩል በፋይበር ቻናል በኩል አገናኝተናል። የተራዘመ የማባዛት ዳታቤዝ የሚዲያ አገልጋዮች ስህተት መቻቻልን አረጋግጠዋል፣ እና እያንዳንዱን አገልጋይ ከእያንዳንዱ CSV ጋር ማገናኘት የትኛውም አካል ካልተሳካ ቀጣይነት ያለው ስራ አስችሏል። የስርዓት አርክቴክቸር ከውሂብ ማእከሎች አንዱ ቢወድቅ እንኳን ምትኬ እንዲቀጥል ይፈቅዳል።

Patroni ለእያንዳንዱ ዘለላ ዋና መስቀለኛ መንገድን ይገልጻል። በመረጃ ማእከል ውስጥ ማንኛውም ነፃ መስቀለኛ መንገድ ሊሆን ይችላል - ግን በአብዛኛው። በመጠባበቂያው ውስጥ፣ ሁሉም አንጓዎች ሁለተኛ ደረጃ ናቸው።

Commvault የትኛው የክላስተር መስቀለኛ መንገድ ዋና እንደሆነ እንዲረዳ፣ ስርዓቱን (ለመፍትሔው ክፍት አርክቴክቸር ምስጋና ይግባውና) ከ Postgres ጋር አዋህደነዋል። ለዚሁ ዓላማ፣ የዋናው መስቀለኛ መንገድ አሁን ያለበትን ቦታ ለCommvault አስተዳደር አገልጋይ የሚዘግብ ስክሪፕት ተፈጠረ።

በአጠቃላይ ሂደቱ ይህን ይመስላል።

Patroni ፕራይመሪ ይመርጣል → Keepalived የአይፒ ክላስተርን ይወስድና ስክሪፕቱን ያስኬዳል → በተመረጠው የክላስተር መስቀለኛ መንገድ ላይ ያለው Commvault ወኪል ይህ ዋና → Commvault በራስሰር የውሸት ደንበኛ ውስጥ ምትኬን እንደገና ያዋቅራል።

የዚህ አቀራረብ ጥቅሙ መፍትሄው የ Postgres ምሳሌን ወጥነት, ትክክለኛነት, ወይም መልሶ ማግኘት ላይ ተጽእኖ አያመጣም. እንዲሁም በቀላሉ ሊሰፋ የሚችል ነው, ምክንያቱም ከአሁን በኋላ የ Commvault የመጀመሪያ እና ሁለተኛ ደረጃ አንጓዎችን ማስተካከል አስፈላጊ አይደለም. ስርዓቱ ዋና የት እንዳለ መረዳቱ በቂ ነው ፣ እና የአንጓዎች ብዛት ወደ ማንኛውም እሴት ሊጨምር ይችላል።

መፍትሄው ተስማሚ መስሎ አይታይም እና የራሱ የሆነ ልዩነት አለው. Commvault ምትኬ ማድረግ የሚችለው ሙሉውን ምሳሌ ብቻ ነው እንጂ የግለሰብ ዳታቤዝ አይደለም። ስለዚህ ለእያንዳንዱ የውሂብ ጎታ የተለየ ምሳሌ ተፈጠረ። እውነተኛ ደንበኞች ወደ ምናባዊ አስመሳይ ደንበኞች ይጣመራሉ። እያንዳንዱ Commvault የውሸት ደንበኛ የ UNIX ዘለላ ነው። የ Postgres Commvault ወኪል የተጫነባቸው የክላስተር ኖዶች ተጨምረዋል። በውጤቱም፣ ሁሉም የሐሰት ደንበኛ ምናባዊ ኖዶች እንደ አንድ ምሳሌ ይቆማሉ።

በእያንዳንዱ የውሸት ደንበኛ ውስጥ፣ የክላስተር ገባሪ መስቀለኛ መንገድ ይጠቁማል። ለCommvault የእኛ የውህደት መፍትሄ የሚገልጸው ይህንን ነው። የአሠራሩ መርህ በጣም ቀላል ነው-ክላስተር አይፒ በመስቀለኛ መንገድ ላይ ከተነሳ ፣ ስክሪፕቱ በCommvault ወኪል ሁለትዮሽ ውስጥ “ገባሪ መስቀለኛ መንገድ” መለኪያ ያዘጋጃል - በእውነቱ ፣ ስክሪፕቱ በሚፈለገው የማስታወሻ ክፍል ውስጥ “1” ያዘጋጃል ። . ወኪሉ ይህንን ውሂብ ወደ CommServe ያስተላልፋል፣ እና Commvault ከሚፈለገው መስቀለኛ መንገድ ምትኬ ይሰራል። በተጨማሪም, የማዋቀሩ ትክክለኛነት በስክሪፕት ደረጃ ላይ ምልክት ይደረግበታል, ምትኬን ሲጀምሩ ስህተቶችን ለማስወገድ ይረዳል.

በተመሳሳይ ጊዜ, ትላልቅ የውሂብ ጎታዎች RPO እና የመጠባበቂያ መስኮት መስፈርቶችን በማሟላት በበርካታ ክሮች ውስጥ በብሎኮች ውስጥ ይጠበቃሉ. በሲስተሙ ላይ ያለው ጭነት እዚህ ግባ የማይባል ነው: ሙሉ ቅጂዎች ብዙ ጊዜ አይከሰቱም, በሌሎች ቀናት ደግሞ ምዝግብ ማስታወሻዎች ብቻ ይሰበሰባሉ, እና ዝቅተኛ ጭነት በሚኖርበት ጊዜ.

በነገራችን ላይ የ PostgreSQL ማህደር ምዝግብ ማስታወሻዎችን ለመደገፍ የተለየ ፖሊሲዎችን ተግብረናል - በተለያዩ ደንቦች መሰረት ይከማቻሉ, በተለየ የጊዜ ሰሌዳ መሰረት ይገለበጣሉ, እና እነዚህ ምዝግብ ማስታወሻዎች ልዩ መረጃዎችን ስለያዙ ተቀናሽ ማድረግ ለእነሱ አልተፈቀደም.

በመላው የአይቲ መሠረተ ልማት ላይ ወጥነት ያለው መሆኑን ለማረጋገጥ በእያንዳንዱ የክላስተር ኖዶች ላይ የCommvault ፋይል ደንበኞች ተጭነዋል። የ Postgres ፋይሎችን ከመጠባበቂያዎች ያገለላሉ እና ለስርዓተ ክወና እና ለመተግበሪያ ምትኬዎች ብቻ የታሰቡ ናቸው። ይህ የውሂብ ክፍል የራሱ የሆነ የመመሪያ እና የማከማቻ ጊዜም አለው።

በአሁኑ ጊዜ፣ IBS የምርታማነት አገልግሎቶችን አይጎዳውም፣ ነገር ግን ሁኔታው ​​ከተቀየረ Commvault የጭነት መገደብን ማንቃት ይችላል።

ጥሩ ነው? ጥሩ!

ስለዚህ፣ ሊሰራ የሚችል ብቻ ሳይሆን ለ PostgreSQL ክላስተር ጭነት ሙሉ በሙሉ በራስ ሰር የመጠባበቂያ ቅጂ አግኝተናል፣ እና ለድርጅት ጥሪዎች ሁሉንም መስፈርቶች ያሟላል።

የ RPO እና የ RTO መለኪያዎች የ 1 ሰዓት እና 2 ሰዓታት በህዳግ ተሸፍነዋል ፣ ይህ ማለት ስርዓቱ በተከማቸ የውሂብ መጠን ላይ ከፍተኛ ጭማሪም ቢሆን እነሱን ያከብራል ማለት ነው። ከብዙ ጥርጣሬዎች በተቃራኒ፣ PostgreSQL እና የድርጅት አካባቢ በጣም ተስማሚ ሆነው ተገኝተዋል። እና አሁን ለእንደዚህ አይነት ዲቢኤምኤስዎች ምትኬ በተለያዩ ውቅሮች ውስጥ እንደሚቻል ከራሳችን ልምድ እናውቃለን።

በእርግጥ በዚህ መንገድ ሰባት ጥንድ የብረት ቦት ጫማዎችን ማልበስ ፣ ብዙ ችግሮችን ማሸነፍ ፣ ብዙ መሰኪያዎችን በመርገጥ እና በርካታ ስህተቶችን ማረም ነበረብን። አሁን ግን አቀራረቡ ቀድሞውኑ ተፈትኗል እና በከባድ የድርጅት ሁኔታዎች ውስጥ ከባለቤትነት DBMS ይልቅ ክፍት ምንጭን ለመተግበር ሊያገለግል ይችላል።

ከ PostgreSQL ጋር በድርጅት አካባቢ ለመስራት ሞክረዋል?

ደራሲያን

Oleg Lavrenov, የውሂብ ማከማቻ ስርዓቶች ንድፍ መሐንዲስ, Jet Infosystems

ዲሚትሪ ኤሪኪን ፣ በጄት መረጃ ስርዓቶች የኮምፒተር ስርዓቶች ንድፍ መሐንዲስ

ምንጭ: hab.com