መግቢያ

ከተወሰነ ጊዜ በፊት፣ ያልተሳካ ክላስተር የማዘጋጀት ተግባር ተሰጠኝ። PostgreSQLበተመሳሳይ ከተማ ውስጥ በፋይበር በተገናኙ በርካታ የመረጃ ቋቶች ውስጥ የሚሰራ እና የአንድ የመረጃ ማእከል ውድቀት (ለምሳሌ ጥቁር መቋረጥ) መቋቋም ይችላል። ለስህተት መቻቻል ተጠያቂ የሆነ ሶፍትዌር እንደመሆኔ፣ መረጥኩ። ርቀትያልተሳኩ ስብስቦችን ለመፍጠር ይህ ከ RedHat ይፋዊ መፍትሄ ስለሆነ። ጥሩ ነው ምክንያቱም RedHat ለእሱ ድጋፍ ስለሚሰጥ እና ይህ መፍትሔ ሁለንተናዊ (ሞዱል) ስለሆነ. በእሱ እርዳታ ለPostgreSQL ብቻ ሳይሆን ለሌሎች አገልግሎቶችም መደበኛ ሞጁሎችን በመጠቀም ወይም ለተወሰኑ ፍላጎቶች በመፍጠር ስህተት መቻቻልን መስጠት ይቻላል ።

ለዚህ ውሳኔ፣ አንድ ምክንያታዊ ጥያቄ ተነስቷል፡- የተሳካ ክላስተር ምን ያህል ጥፋትን መቋቋም ይችላል? ይህንን ለመመርመር በክላስተር መስቀለኛ መንገድ ላይ የተለያዩ ውድቀቶችን የሚመስል፣ ለማገገም የሚጠባበቅ፣ ያልተሳካውን መስቀለኛ መንገድ የሚመልስ እና በ loop ውስጥ መሞከሩን የሚቀጥል የሙከራ አግዳሚ ወንበር አዘጋጀሁ። መጀመሪያ ላይ ይህ ፕሮጀክት hapgsql ተብሎ ይጠራ ነበር, ነገር ግን ከጊዜ በኋላ አንድ አናባቢ ብቻ ያለው ስም ሰለቸኝ. ስለዚህ፣ ስህተትን የሚቋቋሙ የውሂብ ጎታዎችን (እና ተንሳፋፊ አይፒዎችን ወደ እነርሱ እየጠቆሙ) መሰየም ጀመርኩ። ክሮጋን (ከኮምፒዩተር ጨዋታ የተገኘ ገጸ ባህሪ ፣ ሁሉም አስፈላጊ የአካል ክፍሎች የተባዙበት) ፣ እና አንጓዎች ፣ ስብስቦች እና ፕሮጀክቱ ራሱ tuchanka (ክሮጋኖች የሚኖሩበት ፕላኔት).

አስተዳደር አሁን አጽድቋል በ MIT ፍቃድ ለክፍት ምንጭ ማህበረሰብ ፕሮጀክት ይክፈቱ. README በቅርቡ ወደ እንግሊዘኛ ይተረጎማል (ምክንያቱም የ Pacemaker እና PostgreSQL ገንቢዎች ዋነኛ ሸማቾች ይሆናሉ ተብሎ ስለሚጠበቅ) እና የድሮውን የሩሲያ የ README ስሪት (በከፊል) በዚህ ጽሑፍ መልክ ለማቅረብ ወሰንኩ.

ስብስቦች በምናባዊ ማሽኖች ላይ ተዘርግተዋል። VirtualBox. በአጠቃላይ፣ 12 ቨርቹዋል ማሽኖች (በአጠቃላይ 36ጊቢ) ይሰፍራሉ፣ እነዚህም 4 ያልተሳካ ክላስተሮች (የተለያዩ አማራጮች) ይመሰርታሉ። የመጀመሪያዎቹ ሁለት ዘለላዎች በተለያዩ የመረጃ ማእከላት ውስጥ የሚገኙ ሁለት የ PostgreSQL አገልጋዮችን እና አንድ የጋራ አገልጋይን ያቀፉ ናቸው። ምስክር c የስብስብ መሣሪያ (በሶስተኛ የውሂብ ማዕከል ውስጥ ርካሽ በሆነ ምናባዊ ማሽን ላይ የተስተናገደ) እርግጠኛ አለመሆንን የሚፈታ 50% / 50%የአንድን ሰው ድምጽ በመስጠት. ሦስተኛው ክላስተር በሶስት የመረጃ ማዕከሎች አንድ ጌታ ፣ ሁለት ባሮች ፣ ቁ የስብስብ መሣሪያ. አራተኛው ክላስተር አራት የ PostgreSQL አገልጋዮችን ያቀፈ ነው ፣ በመረጃ ማእከል ሁለት - አንድ ዋና ፣ የተቀረው ቅጂዎች እና እንዲሁም ይጠቀማል። ምስክር c የስብስብ መሣሪያ. አራተኛው ከሁለት ሰርቨሮች ወይም ከአንድ የመረጃ ማእከል ውድቀት ተርፏል። አስፈላጊ ከሆነ ይህ መፍትሄ ወደ ተጨማሪ ቅጂዎች ሊሰፋ ይችላል.

የጊዜ አገልግሎት ntpd እንዲሁም ለስህተት መቻቻል እንደገና ተዋቅሯል ፣ ግን ዘዴውን ይጠቀማል ntpd (የሙት ልጅ ሁነታ). የተጋራ አገልጋይ ምስክር እንደ ማዕከላዊ የኤንቲፒ አገልጋይ ሆኖ ይሰራል፣ ጊዜውን ለሁሉም ዘለላዎች በማከፋፈል ሁሉንም አገልጋዮች እርስ በእርስ በማመሳሰል። ከሆነ ምስክር አልተሳካም ወይም ተገለለ፣ከዚያ ከክላስተር ሰርቨሮች አንዱ (በጥቅሉ ውስጥ) ጊዜውን ማሰራጨት ይጀምራል። ረዳት መሸጎጫ የኤችቲቲፒ ተኪ እንዲሁም ተነስቷል። ምስክርበእሱ እርዳታ ሌሎች ምናባዊ ማሽኖች የዩም ማከማቻዎችን ማግኘት ይችላሉ። እንደ እውነቱ ከሆነ፣ እንደ ትክክለኛ ጊዜ እና ተኪ ያሉ አገልግሎቶች በአብዛኛው የሚስተናገዱት በልዩ አገልጋዮች ላይ ነው፣ እና በዳስ ውስጥ የሚስተናገዱት ምስክር የቨርቹዋል ማሽኖችን እና ቦታን ለመቆጠብ ብቻ።

ስሪቶች

v0. በ VirtualBox 7 ላይ ከ CentOS 11 እና PostgreSQL 6.1 ጋር ይሰራል።

የክላስተር መዋቅር

ሁሉም ዘለላዎች በበርካታ የመረጃ ቋቶች ውስጥ እንዲቀመጡ የተነደፉ፣ በአንድ ጠፍጣፋ አውታረመረብ ውስጥ የተዋሃዱ እና የአንድ የውሂብ ማእከል ውድቀትን ወይም የአውታረ መረብ መነጠልን መቋቋም አለባቸው። ለዛ ነው የማይቻል ነው ለመከላከል ይጠቀሙ የተከፈለ-አንጎል መደበኛ Pacemaker ቴክኖሎጂ ይባላል ስቶኒት (በጭንቅላቱ ውስጥ ያለውን ሌላውን መስቀለኛ መንገድ ያንሱ) ወይም ማጠር. ዋናው ነገር: በክላስተር ውስጥ ያሉት አንጓዎች በአንዳንድ መስቀለኛ መንገዶች ላይ የሆነ ችግር እንዳለ መጠራጠር ከጀመሩ, ምላሽ አይሰጥም ወይም የተሳሳተ ባህሪይ, ከዚያም በ "ውጫዊ" መሳሪያዎች ለምሳሌ በ IPMI ወይም UPS መቆጣጠሪያ ካርድ በግዳጅ ያጠፉት. ነገር ግን ይሄ የሚሰራው ከ IPMI አገልጋይ ወይም UPS አንድ ውድቀት ጋር መስራታቸውን በሚቀጥሉበት ጊዜ ብቻ ነው። እንዲሁም አጠቃላይ የመረጃ ማእከሉ ሳይሳካ ሲቀር (ለምሳሌ ሃይል ሲቀንስ) ከከፋ አስከፊ ውድቀት ለመከላከል አቅዷል። እና እንደዚህ ባለ እምቢታ, ሁሉም ነገር ስቶኒትመሳሪያዎች (IPMI፣ UPS፣ ወዘተ) እንዲሁ አይሰሩም።

ይልቁንስ ስርዓቱ የተመሰረተው በኮረም ሃሳብ ላይ ነው። ሁሉም አንጓዎች ድምጽ አላቸው, እና ከሁሉም አንጓዎች ከግማሽ በላይ የሚያዩት ብቻ ሊሰሩ ይችላሉ. ይህ ቁጥር "ግማሽ + 1" ይባላል ምልአተ ጉባኤ. ምልአተ ጉባኤው ካልተደረሰ፣ መስቀለኛ መንገዱ በአውታረመረብ መገለል ውስጥ እንዳለ እና ሀብቱን ማጥፋት እንዳለበት ይወስናል፣ ማለትም. እንደዛ ነው። የተከፈለ-አንጎል ጥበቃ. ለዚህ ባህሪ ተጠያቂው ሶፍትዌር ካልሰራ, አንድ ጠባቂ, ለምሳሌ, በ IPMI ላይ የተመሰረተ, መስራት አለበት.

የአንጓዎች ቁጥር እኩል ከሆነ (በሁለት የመረጃ ማዕከሎች ውስጥ ያለ ክላስተር) ፣ ከዚያ እርግጠኛ ያልሆነ ተብሎ የሚጠራው ነገር ሊነሳ ይችላል። 50% / 50% (ሃምሳ ሃምሳ) የኔትወርክ ማግለል ክላስተርን በትክክል በግማሽ ሲከፍል. ስለዚህ, ለተመጣጣኝ የአንጓዎች ቁጥር, ተጨምሯል የስብስብ መሣሪያ - በሦስተኛው የመረጃ ማእከል ውስጥ በጣም ርካሽ በሆነው ምናባዊ ማሽን ላይ ሊሰራ የሚችል የማይፈለግ ዴሞን። ድምጹን ለአንዱ ክፍል ይሰጣል (ለሚያየው) እና በዚህም 50%/50% እርግጠኛ አለመሆንን ይፈታል። ምልአተ ጉባኤው የሚሠራበት አገልጋይ ደወልኩለት ምስክር (ቃላት ከ repmgr፣ ወደድኩት)።

ግብዓቶች ከቦታ ወደ ቦታ ሊንቀሳቀሱ ይችላሉ፣ ለምሳሌ፣ ከተሳሳቱ አገልጋዮች ወደ አገልግሎት ሰጪዎች፣ ወይም በስርዓት አስተዳዳሪዎች ትእዛዝ። ደንበኞቻቸው የሚፈልጓቸው ሀብቶች የት እንደሚገኙ ለማወቅ (የት እንደሚገናኙ?) ፣ ተንሳፋፊ አይፒ (ተንሳፋፊ አይፒ). እነዚህ አይፒዎች ናቸው Pacemaker በመስቀለኛ መንገድ (ሁሉም ነገር በጠፍጣፋ አውታረመረብ ውስጥ ነው) ሊንቀሳቀስ የሚችለው። እያንዳንዳቸው ሀብትን (አገልግሎትን) ያመለክታሉ እና ወደዚህ አገልግሎት ለመግባት በሚፈልጉበት ቦታ ላይ ይገኛሉ (በእኛ ሁኔታ የውሂብ ጎታ)።

ቱቻንካ1 (የተጨመቀ እቅድ)

መዋቅር

ሐሳቡ ዝቅተኛ ጭነት ያላቸው ብዙ ትናንሽ የውሂብ ጎታዎች እንዳሉን ነበር, ለዚህም ለንባብ ብቻ ግብይቶች በሞቃት ተጠባባቂ ሁኔታ ውስጥ የወሰነ ባሪያ አገልጋይ ማቆየት የማይጠቅም ነው (እንዲህ ያለ የሃብት ብክነት አያስፈልግም)።

እያንዳንዱ የመረጃ ማዕከል አንድ አገልጋይ አለው። እያንዳንዱ አገልጋይ ሁለት የPostgreSQL ምሳሌዎች አሉት (በ PostgreSQL የቃላት አጠራር ክላስተር ይባላሉ፣ ነገር ግን ግራ መጋባትን ለማስወገድ፣ እኔ አብነቶች ብዬ እጠራቸዋለሁ (ከሌሎች ዳታቤዝ ጋር በማመሳሰል) እና የፔሴሜከር ክላስተር ስብስቦችን ብቻ እጠራለሁ። አንድ ምሳሌ በማስተር ሁነታ ይሰራል፣ እና እሱ ብቻ አገልግሎቶችን ይሰጣል (ተንሳፋፊ አይፒ ብቻ ወደ እሱ ይመራል። ሁለተኛው ምሳሌ ለሁለተኛው የመረጃ ማእከል እንደ ባሪያ ሆኖ ይሰራል, እና አገልግሎት የሚሰጠው ጌታው ካልተሳካ ብቻ ነው. አብዛኛውን ጊዜ ከሁለቱ አንዱ (ጌታው) አገልግሎት ስለሚሰጥ (ጥያቄዎችን ያከናውናል) ሁሉም የአገልጋይ ሃብቶች ለዋናው የተመቻቹ ናቸው (ማስታወሻ ለጋራ_buffers መሸጎጫ ወዘተ ይመደባል) ግን ሁለተኛው ምሳሌ እንዲሁም በቂ ሀብቶች አሉት (ምንም እንኳን በፋይል ስርዓት መሸጎጫ በኩል ጥሩ ያልሆነ ሥራ ቢሆንም) ከመረጃ ማእከሎች አንዱ ካልተሳካ። ባሪያው በተመሳሳይ ማሽን ላይ ከጌታው ጋር ለሀብቶች ጦርነት እንዳይኖር በመደበኛ ክላስተር በሚሠራበት ጊዜ አገልግሎቶችን አይሰጥም (የተነበቡ ጥያቄዎችን ብቻ አያከናውንም)።

በሁለት አንጓዎች ላይ ስህተትን መቻቻል የሚቻለው በተመሳሰል ማባዛት ብቻ ነው ምክንያቱም በተመሳሰለ ማባዛት የባሪያው ውድቀት ወደ ጌታው መቆም ያስከትላል።

አለመመስከር

አለመመስከር (የስብስብ መሣሪያ) እኔ ለ Tuchanka1 ክላስተር ብቻ ግምት ውስጥ አደርጋለሁ, ተመሳሳይ ታሪክ ከሌሎቹ ሁሉ ጋር ይሆናል. ምስክር ካልተሳካ, በክላስተር መዋቅር ውስጥ ምንም ነገር አይለወጥም, ሁሉም ነገር በተሰራበት መንገድ መስራቱን ይቀጥላል. ነገር ግን ምልአተ ጉባኤው 2 ከ 3 ይሆናል፣ እና ስለዚህ ማንኛውም ቀጣይ ውድቀት ለክላስተር ገዳይ ነው። አሁንም በአስቸኳይ መደረግ አለበት።

Tuchanka1 አለመቀበል

ለTuchanka1 የውሂብ ማእከሎች የአንዱ ውድቀት። በዚህ ጉዳይ ላይ ምስክር በሁለተኛው የመረጃ ማእከል ውስጥ ወደ ሁለተኛው መስቀለኛ መንገድ ድምጽ ይሰጣል. እዚያም የቀድሞው ባሪያ ወደ ጌታነት ይለወጣል, በውጤቱም, ሁለቱም ጌቶች በአንድ አገልጋይ ላይ ይሰራሉ ​​እና ሁለቱም ተንሳፋፊ አይፒዎች ወደ እነርሱ ያመለክታሉ.

ቱቻንካ2 (አንጋፋ)

መዋቅር

የሁለት አንጓዎች ክላሲክ እቅድ። ጌታው በአንዱ ላይ ይሠራል, ባሪያው በሁለተኛው ላይ ይሠራል. ሁለቱም ጥያቄዎችን ሊፈጽሙ ይችላሉ (ባሪያው የሚነበበው ብቻ ነው)፣ ስለዚህ ሁለቱም በተንሳፋፊ IP ይጠቁማሉ፡ ክሮጋን2 ጌታው ነው፣ krogan2s1 ባሪያ ነው። ጌታውም ባሪያውም ጥፋትን ይታገሣል።

በሁለት አንጓዎች ላይ ስህተትን መቻቻል የሚቻለው ባልተመሳሰል ማባዛት ብቻ ነው, ምክንያቱም በተመሳሰለ ማባዛት, የባሪያው ውድቀት ወደ ጌታው መቆሙን ያመጣል.

Tuchanka2 አለመቀበል

ከዳታ ማእከሎች አንዱ ካልተሳካ ምስክር ለሁለተኛው ድምጽ ይስጡ. ብቸኛው የሚሰራ የውሂብ ማእከል ላይ ጌታው ይነሳል, እና ሁለቱም ተንሳፋፊ አይፒዎች ወደ እሱ ይጠቁማሉ-ጌታ እና ባሪያ. እርግጥ ነው, ምሳሌው ከዋናው እና ከባሪያ ተንሳፋፊ አይፒ ሁሉንም ግንኙነቶች እና ጥያቄዎችን በአንድ ጊዜ ለመቀበል በቂ ሀብቶች (የግንኙነት ገደቦች, ወዘተ) እንዲኖሩት መዋቀር አለበት. ያም ማለት በተለመደው ቀዶ ጥገና ወቅት ለገደቦች በቂ የሆነ ህዳግ ሊኖረው ይገባል.

ቱቻንካ4 (ብዙ ባሮች)

መዋቅር

ቀድሞውኑ ሌላ ጽንፍ. ብዙ ተነባቢ-ብቻ ጥያቄዎች (በጣም የተጫነ ጣቢያ የተለመደ ጉዳይ) ያላቸው የውሂብ ጎታዎች አሉ። Tuchanka4 እንደዚህ አይነት ጥያቄዎችን የሚያስተናግዱ ሶስት ወይም ከዚያ በላይ ባሪያዎች ሊኖሩ የሚችሉበት ሁኔታ ነው, ነገር ግን አሁንም በጣም ብዙ አይደሉም. በጣም ብዙ ቁጥር ባላቸው ባሮች, የተዋረድ የማባዛት ስርዓት መፍጠር አስፈላጊ ይሆናል. በትንሹ (በሥዕሉ ላይ) እያንዳንዱ ሁለቱ የውሂብ ማዕከሎች ሁለት አገልጋዮች አሏቸው, እያንዳንዳቸው የ PostgreSQL ምሳሌ አላቸው.

የዚህ እቅድ ሌላ ገፅታ አንድ የተመሳሰለ ብዜት እዚህ ማደራጀት አስቀድሞ መቻል ነው። ከተቻለ ወደ ሌላ የውሂብ ማዕከል ለመድገም ነው የተዋቀረው እንጂ እንደ ጌታው በተመሳሳይ የውሂብ ማዕከል ውስጥ ላለ ቅጂ አይደለም። ጌታው እና እያንዳንዱ ባሪያ በተንሳፋፊ አይፒ ይጠቁማሉ። ለጥሩ ሁኔታ, በባሮቹ መካከል አንድ ዓይነት የጥያቄዎች ማመጣጠን አስፈላጊ ይሆናል sql ተኪለምሳሌ, በደንበኛው በኩል. የተለያዩ አይነት ደንበኞች የተለያዩ አይነት ሊፈልጉ ይችላሉ sql ተኪ, እና ማን እንደሚያስፈልገው የሚያውቁት ደንበኛው ገንቢዎች ብቻ ናቸው. ይህ ተግባር በውጫዊ ዴሞን ወይም በደንበኛ ቤተ-መጽሐፍት (ግንኙነት ገንዳ) ወዘተ ሊተገበር ይችላል። ይህ ሁሉ ከመረጃ ቋቱ ያልተሳካ ክላስተር ወሰን በላይ ነው። SQL ፕሮክሲ ከደንበኛው ውድቀት ጋር በተናጥል ሊተገበር ይችላል)።

Tuchanka4 አለመቀበል

አንድ የመረጃ ማዕከል (ማለትም ሁለት አገልጋዮች) ካልተሳካ፣ ምስክር ለሁለተኛው ድምጽ ይሰጣል። በውጤቱም, በሁለተኛው የመረጃ ማእከል ውስጥ ሁለት ሰርቨሮች ይሠራሉ: ጌታው በአንዱ ላይ ይሰራል, እና ዋናው ተንሳፋፊ IP ይጠቁማል (የንባብ-ጽሑፍ ጥያቄዎችን ለመቀበል); እና የተመሳሰለ ማባዛት ያለው ባሪያ በሁለተኛው አገልጋይ ላይ እየሄደ ነው፣ እና ከባሪያው ተንሳፋፊ አይፒዎች አንዱ ወደ እሱ ይጠቁማል (ለተነባቢ ጥያቄዎች)።

ሊታወቅ የሚገባው የመጀመሪያው ነገር: ሁሉም የባሪያ ተንሳፋፊ አይፒዎች አይሰሩም, ግን አንድ ብቻ. እና ከእሱ ጋር በትክክል ለመስራት, ይህ አስፈላጊ ይሆናል sql ተኪ ሁሉንም ጥያቄዎች ወደ ቀሪው ተንሳፋፊ አይ.ፒ. እና ከሆነ sql ተኪ የለም፣ ሁሉንም ተንሳፋፊ የአይፒ ባሮች በነጠላ ሰረዞች የተለዩትን በግንኙነት ዩአርኤል ውስጥ መዘርዘር ይችላሉ። በዚያ ሁኔታ, ጋር libpq ግንኙነቱ በአውቶማቲክ የሙከራ ስርዓት ውስጥ እንደሚደረገው ከመጀመሪያው የሚሰራ አይፒ ጋር ይሆናል። ምናልባት በሌሎች ቤተ-መጻሕፍት ውስጥ, ለምሳሌ, JDBC, ይህ አይሰራም እና አስፈላጊ ነው sql ተኪ. ይህ የሚደረገው ምክንያቱም ተንሳፋፊ አይፒ ለባሮች በአንድ ጊዜ በአንድ አገልጋይ ላይ መነሳት የተከለከለ ነው ፣ ስለሆነም ብዙዎቹ ካሉ በባሪያ አገልጋዮች መካከል በእኩል ይሰራጫሉ።

ሁለተኛ፡ የውሂብ ማእከል ብልሽት ቢያጋጥም እንኳን የተመሳሰለ ማባዛት ይቆያል። እና ምንም እንኳን ሁለተኛ ደረጃ ውድቀት ቢከሰት ፣ ማለትም ፣ ከሁለቱ አገልጋዮች አንዱ በቀሪው የመረጃ ማእከል ውስጥ ቢወድቅ ፣ ክላስተር ምንም እንኳን አገልግሎት መስጠት ቢያቆምም ፣ ድርጊቱን ስላረጋገጠባቸው ሁሉም ግብይቶች መረጃ ይይዛል (ይኖራል) በሁለተኛ ደረጃ ውድቀት ላይ ምንም የጠፋ መረጃ መሆን የለበትም)።

Tuchanka3 (3 የውሂብ ማዕከሎች)

መዋቅር

ይህ ሶስት ሙሉ ለሙሉ የሚሰሩ የውሂብ ማእከሎች ባሉበት ሁኔታ ላይ የሚገኝ ስብስብ ነው, እያንዳንዱም ሙሉ በሙሉ የሚሰራ የውሂብ ጎታ አገልጋይ አለው. በዚህ ጉዳይ ላይ የስብስብ መሣሪያ አያስፈልግም. አንድ ጌታ በአንድ የመረጃ ማዕከል ውስጥ ይሰራል, እና ባሮች በሌሎቹ ሁለት ውስጥ ይሰራሉ. ማባዛት የተመሳሰለ ነው፣ እንደ ማንኛውም (ባሪያ1፣ ባሪያ2)፣ ማለትም፣ ማንኛውም ባሪያ ወንጀሉን ተቀብያለሁ ብሎ ሲመልስ ደንበኛው የቃል ማረጋገጫ ይቀበላል። ግብዓቶች በአንድ ተንሳፋፊ አይፒ ለጌታ እና ሁለት ለባሮች ይጠቁማሉ። እንደ Tuchanka4፣ ሦስቱም ተንሳፋፊ አይፒዎች ጥፋቶችን ታጋሽ ናቸው። የተነበበ-ብቻ SQL መጠይቆችን ለማመጣጠን መጠቀም ይችላሉ። sql ተኪ (በተለየ የስህተት መቻቻል) ፣ ወይም አንድ ባሪያ አይፒ ተንሳፋፊን ከደንበኞቹ በግማሽ ፣ እና ሁለተኛውን ለሌላው ግማሽ ይመድቡ።

Tuchanka3 አለመቀበል

ከዳታ ማእከሎች አንዱ ካልተሳካ ሁለቱ ይቀራሉ። በአንደኛው ፣ ጌታው እና ተንሳፋፊው አይፒ ከጌታው ይነሳሉ ፣ በሁለተኛው ውስጥ ፣ ባሪያው እና ሁለቱም ባሪያ ተንሳፋፊ አይፒዎች (ከሁለቱም ባሪያ ተንሳፋፊ አይፒዎች ሁሉንም ግንኙነቶች ለመቀበል በምሳሌው ላይ ድርብ ሀብት ክምችት መኖር አለበት)። በጌቶች እና በባሪያዎች መካከል የተመሳሰለ ማባዛት። እንዲሁም ክላስተር ሁለት የመረጃ ማእከሎች ቢወድሙ (በተመሳሳይ ጊዜ ካልተበላሹ) ስለተፈፀሙ እና የተረጋገጡ ግብይቶች መረጃን ይቆጥባል (የመረጃ መጥፋት አይኖርም)።

የፋይል አወቃቀሩን እና የስርጭቱን ዝርዝር መግለጫ ላለማካተት ወሰንኩ. መጫወት ከፈለጉ ይህንን ሁሉ በ README ውስጥ ማንበብ ይችላሉ። ስለ ራስ-ሰር ሙከራ መግለጫ ብቻ እሰጣለሁ.

ራስ-ሰር የሙከራ ስርዓት

የክላስተሮችን ስህተት መቻቻል የተለያዩ ጥፋቶችን በመምሰል ለማረጋገጥ አውቶማቲክ የፍተሻ ሥርዓት ተሠርቷል። በስክሪፕት የተጀመረ test/failure. ስክሪፕቱ ለመፈተሽ የሚፈልጓቸውን የክላስተር ቁጥሮች እንደ መመዘኛ ሊወስድ ይችላል። ለምሳሌ ይህ ትእዛዝ፡-

test/failure 2 3

ሁለተኛውን እና ሶስተኛውን ክላስተር ብቻ ይፈትሻል. መለኪያዎች ካልተገለጹ፣ ሁሉም ስብስቦች ይሞከራሉ። ሁሉም ስብስቦች በትይዩ ተፈትነዋል እና ውጤቱ በ tmux ፓነል ውስጥ ይታያል። Tmux ራሱን የቻለ tmux አገልጋይ ይጠቀማል፣ስለዚህ ስክሪፕቱ ከነባሪው tmux ስር ሊሄድ ይችላል፣ይህም የጎጆ tmux ያስከትላል። ተርሚናልን በትልቅ መስኮት እና በትንሽ ቅርጸ-ቁምፊ እንዲጠቀሙ እመክራለሁ. ሙከራውን ከመጀመርዎ በፊት ስክሪፕቱ በሚያልቅበት ጊዜ ሁሉም ምናባዊ ማሽኖች ወደ ቅጽበታዊ ገጽ እይታ ይመለሳሉ setup.

ተርሚናሉ በተፈተኑ ክላስተር ብዛት መሰረት ወደ አምዶች የተከፈለ ነው፣ በነባሪ (በቅጽበታዊ ገጽ እይታ) አራቱም አሉ። Tuchanka2 በመጠቀም የአምዶችን ይዘት እንደ ምሳሌ እገልጻለሁ. በቅጽበታዊ ገጽ እይታ ውስጥ ያሉት ፓነሎች ተቆጥረዋል፡-

1. የሙከራ ስታቲስቲክስ የሚታየው እዚህ ነው። ተናጋሪዎች፡-
   • አለመሳካት - ውድቀትን የሚመስለው የፈተናው ስም (በስክሪፕቱ ውስጥ ያለው ተግባር)።
   • ምላሽ - ክላስተር አፈፃፀሙን ወደነበረበት የተመለሰበት የሂሳብ አማካይ ጊዜ በሰከንዶች ውስጥ። የሚለካው ስክሪፕቱ ከጀመረበት ጊዜ ጀምሮ ውድቀትን ከሚመስለው እና ክላስተር ጤንነቱን እስከሚያድስበት እና አገልግሎቱን መቀጠል እስከሚችልበት ቅጽበት ድረስ ነው። ጊዜው በጣም አጭር ከሆነ ለምሳሌ ስድስት ሰከንድ (ይህ ከበርካታ ባሮች (Tuchanka3 እና Tuchanka4) ጋር በክላስተር ውስጥ ይከሰታል) ይህ ማለት ብልሽቱ ባልተመሳሰለ ባሪያ ላይ አብቅቷል እና በምንም መንገድ አፈፃፀም ላይ ተጽዕኖ አላሳደረም ፣ ምንም አልነበሩም። የክላስተር ግዛት መቀየሪያዎች.
   • ማዛባት - የእሴቱን ስርጭት (ትክክለኛነት) ያሳያል ምላሽ በመደበኛ ልዩነት ዘዴ.
   • ተጐዳሁ: ይህ ምርመራ ስንት ጊዜ ተከናውኗል።
2. አጭር ማስታወሻ ክላስተር በአሁኑ ጊዜ ምን እየሰራ እንደሆነ ለመገምገም ይፈቅድልዎታል. የድግግሞሹ (የሙከራ) ቁጥር፣ የጊዜ ማህተም እና የክወና ስም ይታያል። በጣም ረጅም አፈፃፀም (> 5 ደቂቃዎች) አንድ ዓይነት ችግርን ያሳያል።
3. ልብ (ልብ) የአሁኑ ጊዜ ነው። ለእይታ አፈጻጸም ግምገማ ጌታ የአሁኑ ጊዜ የጌታውን ተንሳፋፊ አይፒ በመጠቀም ወደ ጠረጴዛው በቋሚነት ይፃፋል። ከተሳካ ውጤቱ በዚህ ፓነል ውስጥ ይታያል.
4. መምታት (pulse) - "የአሁኑ ጊዜ", ቀደም ሲል በስክሪፕቱ የተመዘገበ ልብ ለማስተማር ፣ አሁን ከ ያንብቡ ባሪያ በእሱ ተንሳፋፊ አይፒ በኩል። የባሪያን አፈጻጸም እና ማባዛትን በእይታ እንዲገመግሙ ያስችልዎታል። በቱቻንካ1 ውስጥ ተንሳፋፊ አይፒ ያላቸው ባሮች የሉም (አገልግሎት የሚሰጡ ባሪያዎች የሉም) ግን ሁለት አጋጣሚዎች (ዲቢ) አሉ ፣ ስለዚህ እዚህ አይታይም መምታትና ልብ ሁለተኛ ምሳሌ.
5. መገልገያውን በመጠቀም የክላስተር ሁኔታን መከታተል pcs mon. አወቃቀሩን, የሃብት ስርጭትን በአንጓዎች እና ሌሎች ጠቃሚ መረጃዎችን ያሳያል.
6. ከእያንዳንዱ ክላስተር ቨርቹዋል ማሽን የስርዓት ክትትልን ያሳያል። ብዙ እንደዚህ ያሉ ፓነሎች ሊኖሩ ይችላሉ - ክላስተር ስንት ምናባዊ ማሽኖች አሉት። ሁለት ግራፎች የሲፒዩ ጭነት (በምናባዊ ማሽኖች ውስጥ ሁለት ፕሮሰሰር)፣ የምናባዊ ማሽን ስም፣ የስርዓት ጭነት (በአማካኝ ከ5፣ 10 እና 15 ደቂቃዎች በላይ ስለነበረ ሎድ አማካኝ ይባላል)፣ የሂደት ውሂብ እና የማህደረ ትውስታ ድልድል።
7. ፈተናዎችን የሚያከናውነውን ስክሪፕት መከታተል. ብልሽት በሚፈጠርበት ጊዜ - ድንገተኛ የሥራ መቋረጥ ወይም ማለቂያ የሌለው የጥበቃ ዑደት - እዚህ ለዚህ ባህሪ ምክንያቱን ማየት ይችላሉ.

ሙከራ በሁለት ደረጃዎች ይካሄዳል. በመጀመሪያ፣ ስክሪፕቱ ሁሉንም ዓይነት ፈተናዎች ያልፋል፣ ይህ ፈተና የሚተገበርበትን ምናባዊ ማሽን በዘፈቀደ ይመርጣል። ከዚያ ማለቂያ የሌለው የሙከራ ዑደት ይከናወናል ፣ ምናባዊ ማሽኖች እና ብልሽቶች በዘፈቀደ በእያንዳንዱ ጊዜ ተመርጠዋል። የፍተሻ ስክሪፕቱ በድንገት መቋረጥ (ከታች ፓነል) ወይም ለአንድ ነገር ማለቂያ የሌለው የጥበቃ ምልልስ (> አንድ ቀዶ ጥገና ለመጨረስ 5 ደቂቃ የሚፈጀው ጊዜ ይህ በክትትል ውስጥ ይታያል) በዚህ ክላስተር ላይ ያሉ አንዳንድ ሙከራዎች እንዳልተሳካላቸው ያሳያል።

እያንዳንዱ ሙከራ የሚከተሉትን ተግባራት ያካትታል:

1. ስህተትን የሚመስል ተግባር መጀመር።
2. ዝግጁ ነዎት? - የክላስተር ጤና ወደነበረበት ለመመለስ በመጠባበቅ ላይ (ሁሉም አገልግሎቶች ሲሰጡ)።
3. የክላስተር መልሶ ማግኛ ጊዜ ታይቷል (ምላሽ).
4. ያስተካክሉ - ክላስተር "ተጠግኖ" ነው. ከዚያ በኋላ ወደ ሙሉ ለሙሉ ወደ ሥራ ሁኔታ መመለስ እና ለቀጣዩ ብልሽት ዝግጁ መሆን አለበት.

የሚሠሩትን መግለጫ የያዘ የፈተናዎች ዝርዝር እነሆ፡-

• ፎርክቦምብበፎርክ ቦምብ "ከማስታወስ ውጭ" ይፈጥራል.
• ከSpace ውጪ: ሃርድ ድራይቭ ሞልቷል. ነገር ግን ፈተናው ተምሳሌታዊ ነው፣ በሙከራ ጊዜ በሚፈጠረው ኢምንት ጭነት፣ ሃርድ ድራይቭ ሲሞላ፣ PostgreSQL አብዛኛውን ጊዜ አይወድቅም።
• ፖስትግሬስ-ገዳይPostgreSQL ን በትእዛዙ ይገድላል killall -KILL postgres.
• postgres-አቁምPostgreSQL ከትእዛዙ ጋር ይሰቅላል killall -STOP postgres.
• ኃይል ዝጋ: ቨርቹዋል ማሽኑን ከትእዛዙ ጋር "de-energizes" VBoxManage controlvm "виртуалка" poweroff.
• ዳግም አስጀምር: ቨርቹዋል ማሽኑን በትእዛዙ እንደገና ይጭናል። VBoxManage controlvm "виртуалка" reset.
• SBD አቁም: የኤስቢዲ ዴሞንን በትእዛዙ አግዶታል። killall -STOP sbd.
• ዝጋውበኤስኤስኤች በኩል ወደ ቨርቹዋል ማሽኑ ትእዛዝ ይልካል systemctl poweroff, ስርዓቱ በጸጋ ይዘጋል.
• ግንኙነት አቋርጥ: የአውታረ መረብ ማግለል, ትዕዛዝ VBoxManage controlvm "виртуалка" setlinkstate1 off.

ሙከራውን በመደበኛ tmux ትዕዛዝ "መግደል-መስኮት" ጨርስ ctrl-b&, ወይም በትእዛዝ "Detach-client" ctrl-bd: በተመሳሳይ ጊዜ, ሙከራው ይጠናቀቃል, tmux ተዘግቷል, ምናባዊ ማሽኖች ጠፍተዋል.

በፈተና ወቅት ተለይተው የሚታወቁ ችግሮች

• በዚህ ወቅት ጠባቂ ዴሞን sbd የተስተዋሉ ዲሞኖችን ያቆማሉ ፣ ግን አይቀዘቅዙም። እናም፣ በውጤቱም፣ ብልሽቶች በስህተት ተሰርተዋል፣ ይህም ወደ በረዶነት ብቻ ይመራል። ኮሮስኒክ и ርቀት, ግን አልተሰቀለም sbd... ለቼክ ኮሮስኒክ ቀድሞውንም አለው PR#83 (በ GitHub በ sbd), ወደ ቅርንጫፍ መቀበል ባለቤት. ለ Pacemaker ተመሳሳይ የሆነ ነገር እንደሚኖር ቃል ገብተዋል (በ PR # 83) ፣ እኔ ተስፋ አደርጋለሁ ሬድሃት 8 ያደርጋል። ነገር ግን እንደዚህ ያሉ “ብልሽቶች” ግምታዊ ናቸው ፣ በቀላሉ በሰው ሰራሽ መንገድ ለምሳሌ ፣ killall -STOP corosyncነገር ግን በእውነተኛ ህይወት ውስጥ ፈጽሞ አይገናኙም.

• У ርቀት በስሪት ውስጥ ለ CentOS 7 በትክክል አልተዘጋጀም። የማመሳሰል_ጊዜ ማብቂያ у የስብስብ መሣሪያበዚህም ምክንያት አንዱ መስቀለኛ መንገድ ካልተሳካ፣ ሁለተኛው መስቀለኛ መንገድ በተወሰነ ዕድል እንደገና ተነሳ, ጌታው መንቀሳቀስ ያለበት. በማጉላት ተፈወሰ የማመሳሰል_ጊዜ ማብቂያ у የስብስብ መሣሪያ በማሰማራት ጊዜ (በስክሪፕት ውስጥ setup/setup1). ይህ ማሻሻያ በገንቢዎች ተቀባይነት አላገኘም። ርቀትይልቁንም የመሠረተ ልማት አውታሮችን እንደገና ለመሥራት ቃል ገብተዋል (በተወሰነ ጊዜ ላልተወሰነ ጊዜ) ይህ የጊዜ ማብቂያ በራስ-ሰር ይሰላል።

• በዳታቤዝ ውቅር ወቅት ከገለጹ LC_MESSAGES (የጽሁፍ መልእክቶች) ዩኒኮድ መጠቀም ይቻላል ለምሳሌ፡- ru_RU.UTF-8, ከዚያም ጅምር ላይ ፖስትጋሮች አካባቢው UTF-8 በማይሆንበት አካባቢ፣ በለው፣ ባዶ አካባቢ (እዚህ ርቀት+pgsqlms(ፓፍ) ይጀምራል ፖስትጋሮች) ፣ ከዚያ ከ UTF-8 ፊደላት ይልቅ በምዝግብ ማስታወሻው ውስጥ የጥያቄ ምልክቶች ይኖራሉ. የ PostgreSQL ገንቢዎች በዚህ ጉዳይ ላይ ምን ማድረግ እንዳለባቸው በጭራሽ አልተስማሙም። ዋጋ ያስከፍላል, ማስቀመጥ ያስፈልግዎታል LC_MESSAGES=en_US.UTF-8 የ DB ምሳሌን ሲያዋቅሩ (ሲፈጠሩ)።

• Wal_receiver_timeout ከተቀናበረ (በነባሪነት 60ዎቹ ነው)፣ ከዚያ PostgreSQL-STOPን ጌታው ላይ በ tuchanka3 እና tuchanka4 ክላስተር ሲሞከር ማባዛት ከአዲስ ጌታ ጋር እንደገና አይገናኝም።. ማባዛት የተመሳሰለ ነው፣ ስለዚህ ባሪያው ብቻ ሳይሆን አዲሱ ጌታም ይቆማል። PostgreSQL ሲያዋቅር wal_receiver_timeout=0 በማቀናበር ያገኛል።

• በForkBomb ፈተና (የማህደረ ትውስታ ብዛት) ላይ የPostgreSQL ድግግሞሽን አልፎ አልፎ አየሁ። ከForkBomb በኋላ፣ አንዳንድ ጊዜ ባሪያዎች ከአዲሱ ጌታ ጋር እንደገና ላይገናኙ ይችላሉ።. ይህንን ያየሁት በ tuchanka3 እና tuchanka4 ስብስቦች ውስጥ ብቻ ነው ፣ እዚያም ማባዛት የተመሳሰለ በመሆኑ ጌታው ሰቅሏል። ችግሩ ከተወሰነ ጊዜ በኋላ (ሁለት ሰዓት ገደማ) በራሱ ጠፋ። ይህንን ለማስተካከል ተጨማሪ ምርምር ያስፈልጋል. ምልክቶቹ ከቀዳሚው ስህተት ጋር ተመሳሳይ ናቸው, ይህም በተለያየ ምክንያት ይከሰታል, ነገር ግን ተመሳሳይ ውጤት አለው.

የ Krogan ሥዕል የተወሰደው ከ ሩካቤ ጥበብ በጸሐፊው ፈቃድ፡-

ምንጭ: hab.com