በ Mail.ru Cloud Solutions መድረክ ላይ ስህተትን የሚቋቋም የድር አርክቴክቸር እንዴት እንደሚተገበር

ሰላም፣ ሃብር! እኔ የስርዓቱ አስተዳደር ቡድን ኃላፊ አርተም ካራሚሼቭ እባላለሁ። የሜይል.ሩ የደመና መፍትሄዎች (ኤምሲኤስ)ባለፈው ዓመት ብዙ አዳዲስ ምርቶችን ጀምረናል። የኤፒአይ አገልግሎቶቻችን በቀላሉ ሊሰፉ የሚችሉ፣ ስህተትን የሚቋቋሙ እና ፈጣን የተጠቃሚ ጭነት እድገትን የሚደግፉ እንዲሆኑ ፈልገን ነበር። መድረካችን በOpenStack ላይ የተገነባ ሲሆን ስህተትን የሚቋቋሙ ስርዓቶችን ለማግኘት መፍታት የነበረብንን የክፍል ስህተትን የሚቋቋሙ ጉዳዮችን ላካፍላችሁ እፈልጋለሁ። ይህ በOpenStack ላይ ምርቶችን ለሚያመርቱ ሰዎችም ትኩረት የሚስብ ይሆናል ብዬ አስባለሁ።

የመድረኩ አጠቃላይ የመቋቋም አቅም የሚወሰነው በክፍሎቹ የመቋቋም አቅም ላይ ነው። ስለዚህ፣ አደጋዎችን ለይተን ባየናቸው እና ባስተካከልናቸው ሁሉም ንብርብሮች ውስጥ ቀስ በቀስ እንሰራለን።

የዚህ ታሪክ የቪዲዮ ቅጂ፣ የመጀመሪያው ምንጭ በUptime day 4 ኮንፈረንስ ላይ የቀረበ አቀራረብ ሲሆን በተዘጋጀው በ ITSumma፣ መመልከት ይችላሉ በUptime Community YouTube ቻናል ላይ.

የአካላዊ አርክቴክቸር የስህተት መቻቻል

የኤምሲኤስ ክላውድ የህዝብ ክፍል በአሁኑ ጊዜ በሁለት የደረጃ III የውሂብ ማዕከላት ላይ የተመሰረተ ሲሆን፣ በተለያዩ አካላዊ ድጋፎች እና 200 Gbps መተላለፊያዎች በተሰራ ልዩ የጥቁር ፋይበር አውታረ መረብ የተገናኘ ነው። ደረጃ III ለአካላዊ መሠረተ ልማቱ አስፈላጊውን የስህተት መቻቻል ደረጃ ይሰጣል።

ጥቁር ፋይበር በአካላዊም ሆነ በሎጂካዊ ደረጃዎች ተደጋጋሚ ነው። የቻናል ድግግሞሽ ሂደቱ ተደጋጋሚ ነበር፣ እና ችግሮች ቢከሰቱም፣ በመረጃ ማዕከላት መካከል ያለውን ግንኙነት ያለማቋረጥ እያሻሻልን ነው።

ለምሳሌ፣ ብዙም ሳይቆይ፣ ከውሂብ ማዕከሎቻችን በአንዱ አቅራቢያ ባለ ጉድጓድ ውስጥ ሲሰራ፣ አንድ ቁፋሮ ዋና እና ምትኬ የፋይበር ኦፕቲክ ገመዶችን የያዘውን ቧንቧ ወጋው። ከውሂብ ማዕከሉ ጋር ያለን ደህንነቱ የተጠበቀ የመገናኛ ቻናል በአንድ ወቅት ማለትም ጉድጓዱ ላይ ተጋላጭ ነበር። በዚህም ምክንያት የመሠረተ ልማታችንን በከፊል አጣን። ከዚህ ተምረን በርካታ እርምጃዎችን ወስደናል፣ ይህም በአጎራባች ጉድጓድ ውስጥ ተጨማሪ የፋይበር ኦፕቲክ ኬብሎችን መትከልን ያካትታል።

የመረጃ ማዕከሎቻችን ቅድመ-ቅጥያዎቻችንን በBGP በኩል የምናስተላልፍላቸው የቴሌኮም አቅራቢዎች የሚገኙባቸውን ቦታዎች ይይዛሉ። ለእያንዳንዱ የአውታረ መረብ አቅጣጫ ምርጡ መለኪያ ይመረጣል፣ ይህም ለተለያዩ ደንበኞች ምርጡን የግንኙነት ጥራት እንድናቀርብ ያስችለናል። በአንድ አቅራቢ በኩል ያለው ግንኙነት ከተቋረጠ፣ በሚገኙ አቅራቢዎች በኩል የማስተላለፊያ መስመራችንን እንደገና እናዋቅራለን።

የአቅራቢው ችግር ሲከሰት፣ በራስ-ሰር ወደሚቀጥለው አቅራቢ እንሸጋገራለን። አንድ የውሂብ ማዕከል ካልተሳካ፣ በሁለተኛው የውሂብ ማዕከል ውስጥ የአገልግሎቶቻችንን መስታወት ቅጂ እናገኛለን፣ ይህም አጠቃላይ ጭነቱን ይወስዳል።

የአካላዊ መሠረተ ልማት መቋቋም

ለመተግበሪያ ደረጃ የስህተት መቻቻል የምንጠቀመው ነገር

አገልግሎታችን የተገነባው በተለያዩ ክፍት ምንጭ ክፍሎች ላይ ነው።

ExaBGP — በBGP ላይ የተመሠረተ ተለዋዋጭ የማዞሪያ ፕሮቶኮልን በመጠቀም በርካታ ተግባራትን የሚያስፈጽም አገልግሎት። ተጠቃሚዎች ኤፒአይን የሚደርሱበትን በነጭ ዝርዝር ውስጥ የተዘረዘሩ የአይፒ አድራሻዎቻችንን ለማስተዋወቅ በንቃት እንጠቀማለን።

HAProxy — ከፍተኛ የጭነት ጭነት ሚዛን ያለው ሲሆን ይህም በተለያዩ የ OSI ሞዴል ንብርብሮች ላይ ከፍተኛ ተለዋዋጭ የትራፊክ ሚዛን ደንቦችን እንዲያዋቅሩ ያስችልዎታል። በሁሉም አገልግሎቶች ላይ የጭነት ሚዛንን ለመጠበቅ እንጠቀምበታለን፡ የውሂብ ጎታዎች፣ የመልእክት ደላሎች፣ የኤፒአይ አገልግሎቶች፣ የድር አገልግሎቶች እና የውስጥ ፕሮጀክቶቻችን - ሁሉም በ HAProxy የተጎላበቱ ናቸው።

የኤፒአይ መተግበሪያ — በፓይቶን የተጻፈ የድር መተግበሪያ፣ ተጠቃሚው መሠረተ ልማቱን፣ አገልግሎታቸውን የሚያስተዳድርበት።

የሰራተኛ ማመልከቻ (ከዚህ በኋላ በቀላሉ ሠራተኛ ተብሎ የሚጠራው) በOpenStack አገልግሎቶች ውስጥ የሚገኝ የመሠረተ ልማት ዲያሞን ሲሆን የኤፒአይ ትዕዛዞች ወደ መሠረተ ልማቱ እንዲተላለፉ ያስችላል። ለምሳሌ፣ የዲስክ ፈጠራ በሠራተኛ ውስጥ ይከሰታል፣ እና የመፍጠር ጥያቄው ወደ API መተግበሪያ ይላካል።

የ OpenStack መተግበሪያ መደበኛ አርክቴክቸር

ለኦፕንስታክ የተዘጋጁ አብዛኛዎቹ አገልግሎቶች የተዋሃደ ፓራዲየም ለመከተል ይሞክራሉ። አንድ አገልግሎት በተለምዶ ሁለት ክፍሎችን ያቀፈ ነው፡ ኤፒአይ እና ሰራተኞች (የኋላ ክንፍ አስፈፃሚዎች)። በተለምዶ፣ ኤፒአይ በፓይዘን የተጻፈ የWSGI መተግበሪያ ሲሆን እንደ ራሱን የቻለ ሂደት (ዴሞን) ወይም እንደ Nginx ወይም Apache ያሉ የድር አገልጋይን ይጠቀማል። ኤፒአይ የተጠቃሚውን ጥያቄ ያስኬዳል እና ለሠራተኛው መተግበሪያ ተጨማሪ መመሪያዎችን ያስተላልፋል። ይህ ስርጭት የሚከሰተው በመልእክት ደላላ፣ በተለምዶ RabbitMQ፣ በኩል ነው፤ ሌሎች ዓይነቶች ደካማ ድጋፍ የላቸውም። መልዕክቶች ደላላው ላይ ሲደርሱ፣ ሰራተኞች ያስኬዷቸዋል እና አስፈላጊ ከሆነም ምላሽ ይመልሳሉ።

ይህ ፓራዲየም የተነጠሉ የተለመዱ የውድቀት ነጥቦችን ያመለክታል፡ RabbitMQ እና የውሂብ ጎታ። ሆኖም ግን፣ RabbitMQ በአንድ አገልግሎት ውስጥ ተነጥሎ የሚገኝ ሲሆን በንድፈ ሀሳብ ለእያንዳንዱ አገልግሎት የተለየ ሊሆን ይችላል። ስለዚህ፣ በMCS፣ እነዚህን አገልግሎቶች በተቻለ መጠን እንለያቸዋለን፣ ለእያንዳንዱ ፕሮጀክት የተለየ የውሂብ ጎታ እና የተለየ RabbitMQ እንፈጥራለን። ይህ አካሄድ ጠቃሚ ነው ምክንያቱም አንድ ውድቀት በተጋለጠ ቦታ ላይ ከተከሰተ፣ የአገልግሎቱ አንድ ክፍል ብቻ ነው፣ ሙሉውን አገልግሎት ሳይሆን፣ የሚጎዳው።

የሰራተኛ አፕሊኬሽኖች ብዛት ገደብ የለውም፣ ስለዚህ ኤፒአይው አፈፃፀምን እና የስህተት መቻቻልን ለመጨመር በቀላሉ ከሚዛንተሮች ጀርባ በአግድም ሊለካ ይችላል።

አንዳንድ አገልግሎቶች በኤፒአይዎች እና በሠራተኞች መካከል ውስብስብ ተከታታይ ክዋኔዎች ሲከሰቱ - በአገልግሎት ውስጥ ቅንጅት ያስፈልጋቸዋል። በዚህ ሁኔታ፣ እንደ ሬድስ፣ ሜምካቼ፣ ወዘተ ያሉ አንድ የማስተባበሪያ ማዕከል ጥቅም ላይ ይውላል፣ ይህም አንድ ሠራተኛ ለሌላው አንድ ተግባር እንደተመደበላቸው ("እባክዎን አይውሰዱት") እንዲናገር ያስችለዋል። ወዘተ እንጠቀማለን። በተለምዶ፣ ሠራተኞች ከመረጃ ቋቱ ጋር በንቃት ይገናኛሉ፣ ከእሱ የሚገኘውን መረጃ ይጽፋሉ እና ያነባሉ። ማሪያድብን እንደ የውሂብ ጎታችን እንጠቀማለን፣ ይህም በብዙ ማስተር ክላስተራችን ውስጥ ይገኛል።

ይህ ክላሲክ ነጠላ አገልግሎት ለኦፕንስታክ በአጠቃላይ ተቀባይነት ባለው መንገድ የተደራጀ ነው። እንደ ዝግ ስርዓት ሊታይ ይችላል፣ በጣም ቀላል የሆነ የመለኪያ እና የስህተት መቻቻል አማራጮች አሉት። ለምሳሌ፣ የኤፒአይ ስህተት መቻቻልን ለማረጋገጥ፣ የጭነት ሚዛን በኤፒአይ ፊት ያስቀምጡ። የሰራተኞች ልኬት የሚሳካው ቁጥራቸውን በመጨመር ነው።

በጠቅላላው እቅድ ውስጥ ያሉት ደካማ ነጥቦች RabbitMQ እና MariaDB ናቸው። የእነሱ አርክቴክቸር የተለየ ጽሑፍ ይገባዋል። በዚህ ጽሑፍ ውስጥ፣ በኤፒአይ ስህተት መቻቻል ላይ ማተኮር እፈልጋለሁ።

የ OpenStack አፕሊኬሽን አርክቴክቸር፡ ለደመና መድረክ ሚዛን እና የስህተት መቻቻል

በ ExaBGP አማካኝነት HAProxy Load Balancer Fault-Tolerant ማድረግ

የኛ ኤፒአይዎች ሊሰፉ የሚችሉ፣ ፈጣን እና ስህተትን የሚቋቋሙ መሆናቸውን ለማረጋገጥ የጭነት ሚዛን አስገብተናል። HAProxyን መርጠናል። በእኔ አስተያየት፣ ለፍላጎታችን የሚያስፈልጉ ሁሉም አስፈላጊ ባህሪያት አሉት፡- በብዙ የ OSI ንብርብሮች ላይ የጭነት ሚዛን፣ የአስተዳደር በይነገጽ፣ ተለዋዋጭነት እና ስፋት፣ ሰፊ የጭነት ሚዛን ዘዴዎች እና የክፍለ ጊዜ ሰንጠረዥ ድጋፍ።

የመጀመሪያው መፍትሔ የሚያስፈልገው የጭነት ማመጣጠኛው ራሱ የስህተት መቻቻል ነበር። የጭነት ማመጣጠኛውን መጫን ብቻ አንድ የውድቀት ነጥብ ይፈጥራል፡ የጭነት ማመጣጠኛው ካልተሳካ አገልግሎቱ ይቀንሳል። ይህንን ለመከላከል HAProxyን ከ ExaBGP ጋር በማጣመር ተጠቅመናል።

ExaBGP የአገልግሎት የጤና ፍተሻ ዘዴን ያስችላል። ይህንን ዘዴ የHAProxyን ጤና ለመፈተሽ እና ችግሮች ከተከሰቱ የHAProxy አገልግሎትን ከBGP ለማሰናከል ተጠቅመንበታል።

ExaBGP+HAProxy Scheme

1. አስፈላጊውን ሶፍትዌር፣ ExaBGP እና HAProxy፣ በሶስት ሰርቨሮች ላይ እንጭናለን።
2. በእያንዳንዱ አገልጋይ ላይ የ loopback በይነገጽ እንፈጥራለን።
3. በሦስቱም አገልጋዮች ላይ፣ በዚህ በይነገጽ ላይ ተመሳሳይ ነጭ የአይፒ አድራሻ እንመዘግባለን።
4. የነጩ የአይፒ አድራሻ በExaBGP በኩል ወደ ኢንተርኔት ይገለፃል።

የስህተት መቻቻል የሚገኘው ከሶስቱም አገልጋዮች ተመሳሳይ የአይፒ አድራሻ በማስተዋወቅ ነው። ከአውታረ መረቡ አንፃር፣ ተመሳሳይ አድራሻ ከሶስት የተለያዩ ቀጣይ መዝለያዎች ተደራሽ ነው። ራውተሩ ሶስት ተመሳሳይ መንገዶችን ያያል፣ በራሱ መለኪያ (ብዙውን ጊዜ ተመሳሳይ መንገድ) ላይ በመመስረት ከፍተኛ ቅድሚያ የሚሰጠውን መንገድ ይመርጣል፣ እና ትራፊክ ወደ አንድ አገልጋይ ብቻ ይመራል።

ከ HAProxy ወይም የአገልጋይ ውድቀት ጋር በተያያዘ ችግሮች ሲከሰቱ፣ ExaBGP መንገዱን ማስተዋወቅ ያቆማል፣ እና ትራፊክ ወደ ሌላ አገልጋይ በተቀላጠፈ ሁኔታ ይቀየራል።

በዚህ መንገድ፣ የባለአደራውን የስህተት መቻቻል አግኝተናል።

HAProxy Load Balancer Fault Tolerance

ማዋቀሩ ፍጹም አልነበረም፡ HAProxyን እንዴት ምትኬ ማስቀመጥ እንደሚቻል ተምረናል፣ ነገር ግን ጭነቱን በአገልግሎቶች ላይ እንዴት ማሰራጨት እንደሚቻል አልተማርንም። ስለዚህ ማዋቀሩን በትንሹ አስፋፍተነው፣ ​​በብዙ የህዝብ አይፒ አድራሻዎች ላይ ወደ ጭነት ሚዛን ቀይረናል።

በዲኤንኤስ ላይ የተመሠረተ የጭነት ሚዛን እና BGP

በ HAProxy ፊት ለፊት ያለው የጭነት ሚዛን አሁንም አልተፈታም። ሆኖም ግን፣ እኛ ለራሳችን እንዳደረግነው ሁሉ በቀላሉ ሊፈታ ይችላል።

ሶስት አገልጋዮችን ለማመጣጠን ሶስት የህዝብ አይፒ አድራሻዎች እና ጥሩ የድሮ ዲኤንኤስ ያስፈልግዎታል። እያንዳንዳቸው እነዚህ አድራሻዎች ለእያንዳንዱ HAProxy የ loopback በይነገጽ የተመደቡ እና ለበይነመረብ የሚተዋወቁ ናቸው።

ኦፕንስታክ የእያንዳንዱን አገልግሎት የኤፒአይ የመጨረሻ ነጥብ የሚገልጽ የአገልግሎት ካታሎግ ይጠቀማል። በዚህ ካታሎግ ውስጥ፣ በዲኤንኤስ በኩል ወደ ሶስት የተለያዩ የአይፒ አድራሻዎች የሚፈታ የጎራ ስም—public.infra.mail.ru—እንገልጻለን። ይህ በዲኤንኤስ በመጠቀም በሦስቱ አድራሻዎች ላይ የጭነት ሚዛን ያስከትላል።

ሆኖም ግን፣ በነጭ የተዘረዘሩ የአይፒ አድራሻዎችን ስናሳውቅ የአገልጋይ ምርጫ ቅድሚያ የሚሰጣቸውን ነገሮች ስለማንቆጣጠር፣ ይህ እስካሁን ሚዛናዊ አይደለም። በተለምዶ፣ አንድ አገልጋይ ብቻ በከፍተኛው የአይፒ አድራሻ ላይ በመመስረት ይመረጣል፣ ሌሎቹ ሁለቱ ደግሞ በBGP ውስጥ ምንም መለኪያዎች ስላልተገለጹ ስራ ፈት ሆነው ይቆያሉ።

በExaBGP በኩል መንገዶችን በተለያዩ መለኪያዎች ማሰራጨት ጀምረናል። እያንዳንዱ የጭነት ሚዛን ሶስቱንም በነጭ ዝርዝር ውስጥ የተዘረዘሩ የአይፒ አድራሻዎችን ያስተዋውቃል፣ ነገር ግን ከነሱ አንዱ፣ ለዚያ የጭነት ሚዛን ዋናው የአይፒ አድራሻ፣ በዝቅተኛ መለኪያ ይገለጻል። ስለዚህ፣ ሦስቱም የጭነት ሚዛን አስተላላፊዎች የሚሰሩ ቢሆኑም፣ ወደ መጀመሪያው የአይፒ አድራሻ የሚላኩ ጥያቄዎች ወደ መጀመሪያው የጭነት ሚዛን አስተላላፊ፣ ወደ ሁለተኛው ወደ ሁለተኛው የሚላኩ ጥያቄዎች እና ወደ ሶስተኛው ወደ ሶስተኛው የሚላኩ ጥያቄዎች ይሄዳሉ።

ከጭነት ማመጣጠኛዎቹ አንዱ ሲከሽፍ ምን ይሆናል? ማንኛውም የጭነት ማመጣጠኛ ካልተሳካ፣ ዋናው አድራሻው በሌሎቹ ሁለቱ ይተዋወቃል፣ እና ትራፊክ በመካከላቸው እንደገና ይሰራጫል። በዚህ መንገድ፣ ለተጠቃሚው በዲኤንኤስ በኩል በርካታ የአይፒ አድራሻዎችን እናቀርባለን። በዲኤንኤስ እና በተለያዩ መለኪያዎች በማመጣጠን፣ የስህተት መቻቻልን እየጠበቅን በሦስቱም የጭነት ማመጣጠኛዎች ላይ እኩል የሆነ የጭነት ስርጭት እናገኛለን።

HAProxy Load Balanceing ከዲ ኤን ኤስ እና ቢጂፒ ጋር

በ ExaBGP እና HAProxy መካከል ያለው መስተጋብር

ስለዚህ፣ የመንገድ ማስታወቂያዎችን በማቆም የአገልጋይ ማቋረጥን ለመከላከል የውድቀት መከላከያ ተግባራዊ አድርገናል። ነገር ግን HAProxy ከአገልጋይ ውድቀት በተጨማሪ በሌሎች ምክንያቶች ሊወድቅ ይችላል፡ የአስተዳደር ስህተቶች፣ የውስጥ አገልግሎት ውድቀቶች። በእነዚህ አጋጣሚዎችም የወረደውን የጭነት ሚዛን ከጭነት ሚዛን ማስወገድ እንፈልጋለን፣ ስለዚህ የተለየ ዘዴ ያስፈልገናል።

ስለዚህ፣ በቀድሞው እቅድ ላይ በመስፋፋት፣ በExaBGP እና HAProxy መካከል የልብ ምት ተግባራዊ አድርገናል። ይህ በExaBGP እና HAProxy መካከል ያለውን መስተጋብር የሚያሳይ የሶፍትዌር ትግበራ ሲሆን፣ ExaBGP የመተግበሪያዎችን ሁኔታ ለመፈተሽ ብጁ ስክሪፕቶችን ይጠቀማል።

ይህንን ለማድረግ፣ የHAProxyን ሁኔታ ማረጋገጥ የሚችል በExaBGP ውቅር ውስጥ የጤና ፈታሽ ማዋቀር ያስፈልግዎታል። በእኛ ሁኔታ፣ በHAProxy ውስጥ የጤና ባክዴን አዋቅረናል፣ እና በExaBGP በኩል ደግሞ በቀላል የGET ጥያቄ እንፈትሻለን። ማስታወቂያው ከቆመ፣ HAProxy ምናልባት እየቀነሰ ሊሆን ይችላል እና ማስታወቂያ መስጠት አያስፈልገውም።

የ HAProxy የጤና ምርመራ

HAProxy Peers: የክፍለ ጊዜ ማመሳሰል

የሚቀጥለው ነገር ክፍለ ጊዜዎችን ማመሳሰል ነበር። ከተከፋፈሉ የጭነት ሚዛን አስተላላፊዎች ጋር ሲሰሩ የደንበኛ ክፍለ ጊዜ መረጃን ማከማቸት አስቸጋሪ ነው። ነገር ግን HAProxy በPeers ባህሪው ምክንያት ይህንን ማድረግ ከሚችሉት ጥቂት የጭነት ሚዛን አስተላላፊዎች አንዱ ሲሆን ይህም የክፍለ ጊዜ ሰንጠረዡ በተለያዩ የHAProxy ሂደቶች መካከል እንዲጋራ ያስችለዋል።

የተለያዩ የማመጣጠን ዘዴዎች አሉ፤ ቀላል ዘዴዎች ለምሳሌ ክብ-ሮቢንእና የተራዘሙ፣ የደንበኛው ክፍለ ጊዜ የሚታወስባቸው እና በእያንዳንዱ ጊዜ ወደ ተመሳሳይ አገልጋይ የሚመሩባቸው። ሁለተኛውን አማራጭ ተግባራዊ ለማድረግ ፈልገን ነበር።

HAProxy የደንበኛ ክፍለ ጊዜዎችን ለማከማቸት የተለጠፈ ጠረጴዛዎችን ይጠቀማል። የደንበኛውን የምንጭ አይፒ አድራሻ፣ የተመረጠውን የዒላማ አድራሻ (የኋላ ክፍል) እና አንዳንድ የአገልግሎት መረጃዎችን ያከማቻሉ። የተለጠፈ ጠረጴዛዎች በተለምዶ የምንጭ-አይፒ እና የመድረሻ-አይፒ ጥንዶችን ለማከማቸት ያገለግላሉ፣ ይህም በተለይ ወደ ሌላ የጭነት ሚዛን ሲቀይሩ የተጠቃሚ ክፍለ ጊዜ አውድ ማስተላለፍ ለማይችሉ መተግበሪያዎች ጠቃሚ ነው፣ ለምሳሌ በRoundRobin የጭነት ሚዛን ሁነታ።

የዱላ ጠረጴዛውን በተለያዩ የHAProxy ሂደቶች (በመካከላቸው የጭነት ሚዛን በሚከሰትባቸው) መካከል እንዲንቀሳቀስ በማስተማር፣ የጭነት ሚዛኖቻችን ከአንድ የዱላ ጠረጴዛዎች ጋር አብረው መሥራት ይችላሉ። ይህ አንድ የጭነት ሚዛኖ ማሽን ካልተሳካ እንከን የለሽ የደንበኛ አውታረ መረብ ብልሽት እንዲኖር ያስችላል፣ እና የደንበኛ ክፍለ ጊዜዎች ቀደም ሲል በተመረጡት ተመሳሳይ የኋላ ጫፎች ላይ መስተናገዳቸውን ይቀጥላሉ።

ለትክክለኛ አሠራር፣ ክፍለ ጊዜው የተቋቋመበት የሎድ ባላጀር ምንጭ የአይፒ አድራሻ ላይ ያለው ችግር መፍታት አለበት። በእኛ ሁኔታ፣ ይህ በሉፕባክ በይነገጽ ላይ ተለዋዋጭ አድራሻ ነው።

አቻዎች በትክክል የሚሰሩት በተወሰኑ ሁኔታዎች ውስጥ ብቻ ነው። በተለይም የTCP የጊዜ ማብቂያዎች በቂ ረጅም መሆን አለባቸው፣ አለበለዚያ የTCP ክፍለ ጊዜ እንዳይቋረጥ ለመከላከል የመቀየሪያው ፍጥነት ፈጣን መሆን አለበት። ሆኖም፣ ይህ ያለምንም እንከን መቀያየርን ያስችላል።

በIaaS ውስጥ ተመሳሳይ ቴክኖሎጂን በመጠቀም የተገነባ አገልግሎት አለን። ለ OpenStack እንደ አገልግሎት የሎድ ባላነርኦክታቪያ ይባላል። በሁለት የHAProxy ሂደቶች ላይ የተመሰረተ ሲሆን ለእኩዮችም የራሱ የሆነ ድጋፍ አለው። ለዚህ አገልግሎት በጣም ጥሩ መሆናቸውን አረጋግጠዋል።

ምስሉ በሶስት HAProxy አብነቶች መካከል የአቻ ሰንጠረዦችን እንቅስቃሴ በንድፍ ያሳያል፣ እና ይህ እንዴት ሊዋቀር እንደሚችል ለማሳየት ውቅር ቀርቧል፡

HAProxy Peers (የክፍለ ጊዜ ማመሳሰል)

ተመሳሳይ ዘዴ ተግባራዊ ካደረጉ በጥንቃቄ መሞከር አለብዎት። 100% ጊዜ እንደሚሰራ ዋስትና አይሰጥም። ነገር ግን የደንበኛውን የምንጭ አይፒ ማስታወስ ሲያስፈልግዎ ቢያንስ ተለጣፊ ጠረጴዛዎችዎን አያጡም።

ከተመሳሳይ ደንበኛ የሚመጡ በአንድ ጊዜ የሚጠየቁ ጥያቄዎችን ብዛት መገደብ

ማንኛውም ለሕዝብ ተደራሽ የሆነ አገልግሎት፣ የእኛን ኤፒአይ ጨምሮ፣ ለብዙ ጥያቄዎች ሊጋለጥ ይችላል። መንስኤዎቹ ከተጠቃሚ ስህተቶች እስከ ኢላማ የተደረጉ ጥቃቶች በስፋት ሊለያዩ ይችላሉ። በየጊዜው የአይፒ DDoS ጥቃቶችን እናጋጥማለን። ደንበኞች ብዙውን ጊዜ በስክሪፕቶቻቸው ላይ ስህተቶችን ስለሚያደርጉ አነስተኛ-DDoS ጥቃቶችን ያስከትላሉ።

ያም ሆነ ይህ፣ ተጨማሪ የደህንነት እርምጃዎች አስፈላጊ ናቸው። ግልጽ የሆነ መፍትሔ የኤፒአይ ጥያቄዎችን ብዛት መገደብ እና ተንኮል አዘል ጥያቄዎችን በማስኬድ የሲፒዩ ጊዜን ከማባከን መቆጠብ ነው።

እነዚህን ገደቦች ተግባራዊ ለማድረግ፣ ተመሳሳይ የዱላ ሰንጠረዦችን በመጠቀም በHAProxy ላይ የተገነቡ የዋጋ ገደቦችን እንጠቀማለን። ገደቦቹ ለማዋቀር በጣም ቀላል ናቸው እና ተጠቃሚው ሊያደርጋቸው የሚችላቸውን የኤፒአይ ጥያቄዎች ብዛት እንዲገድቡ ያስችሉዎታል። ስልተ ቀመሩ ጥያቄዎች የሚቀርቡበትን የምንጭ አይፒ ያስታውሳል እና በአንድ ተጠቃሚ የሚጠየቁትን በአንድ ጊዜ የሚጠየቁ ጥያቄዎችን ብዛት ይገድባል። በተፈጥሮ፣ ለእያንዳንዱ አገልግሎት አማካይ የኤፒአይ ጭነት መገለጫ አስልተን ከዚህ እሴት በግምት 10 እጥፍ የሚበልጥ ገደብ አስቀምጠናል። ሁኔታውን በቅርበት መከታተል እንቀጥላለን፣ ጣታችንን በድብሉ ላይ እናቆየዋለን።

ይህ በተግባር እንዴት ይሰራል? ኤፒአይዎቻችንን ለአውቶስኬሊንግ ያለማቋረጥ የሚጠቀሙ ደንበኞች አሉን። ጠዋት ከሁለት እስከ ሶስት መቶ የሚሆኑ ምናባዊ ማሽኖችን ይፈጥራሉ እና ምሽት ላይ ይሰርዛሉ። ለኦፕንስታክ፣ በተለይም ከፓኤኤስ አገልግሎቶች ጋር ምናባዊ ማሽን መፍጠር ቢያንስ 1000 የኤፒአይ ጥያቄዎችን ይፈልጋል፣ ምክንያቱም በአገልግሎቶች መካከል ያለው መስተጋብር በኤፒአይዎች በኩልም ይከሰታል።

እነዚህ የተግባር ዝውውሮች በጣም ጉልህ የሆነ ጭነት ይፈጥራሉ። ይህንን ጭነት ገምግመናል፣ ዕለታዊ ከፍተኛ ደረጃዎችን ሰብስበናል፣ በአስር እጥፍ ጨምረናል፣ እናም ይህ የእኛ የፍጥነት ገደብ ሆነ። ጣታችንን በኃይል ላይ እናስቀምጣለን። ብዙ ጊዜ ሊሰሩ የሚችሉ የCGA ስክሪፕቶች እንዳሉን ለማየት የሚሞክሩ ቦቶችን እና ስካነሮችን እናያለን፣ እና በንቃት እንቆርጣቸዋለን።

የኮድቤዝዎን ለተጠቃሚዎች ያለምንም እንከን እንዴት ማዘመን እንደሚቻል

በኮድ ማሰማራት ሂደት ደረጃ የስህተት መቻቻልንም ተግባራዊ እናደርጋለን። በማሰማራት ጊዜ ውድቀቶች ይከሰታሉ፣ ነገር ግን በአገልግሎት አቅርቦት ላይ ያላቸው ተጽእኖ ሊቀንስ ይችላል።

አገልግሎቶቻችንን ያለማቋረጥ እናዘምናለን እና የኮድቤዝ ዝማኔዎች ተጠቃሚዎችን ሳይነኩ መከናወናቸውን ማረጋገጥ አለብን። ይህንንም የHAProxyን የአስተዳደር ችሎታዎች በመጠቀም እና በአገልግሎቶቻችን ውስጥ የGraceful Shutdown ን በመተግበር አሳክተናል።

ይህንን ችግር ለመፍታት፣ የሒሳብ ሚዛን አስተዳደርን እና የአገልግሎት "ትክክል" መዘጋትን ማረጋገጥ አስፈላጊ ነበር፡

• በ HAProxy፣ አስተዳደር የሚስተናገደው በስታቲስቲክስ ፋይል በኩል ሲሆን ይህም በመሠረቱ በ HAProxy ውቅር ፋይል ውስጥ በተገለጸ ሶኬት ነው። ትዕዛዞች በ stdio በኩል ወደ እሱ ሊተላለፉ ይችላሉ። ሆኖም፣ ዋናው የውቅር አስተዳደር መሳሪያችን Ansible ነው፣ ስለዚህ HAProxyን ለማስተዳደር አብሮ የተሰራ ሞጁል አለው፣ እሱም በንቃት የምንጠቀምበት።
• አብዛኛዎቹ የኤፒአይ እና የኢንጂን አገልግሎቶቻችን ማራኪ የሆነ የመዝጋት ተግባርን ይደግፋሉ፡ ሲዘጋ፣ የአሁኑን ተግባር፣ የኤችቲቲፒ ጥያቄ ይሁን ሌላ የአገልግሎት ተግባር፣ እስኪጠናቀቅ ድረስ ይጠብቃሉ። በሠራተኛ ላይም ተመሳሳይ ነገር ይከሰታል። የሚያከናውናቸውን ተግባራት ሁሉ ያውቃል እና ሁሉም በተሳካ ሁኔታ ሲጠናቀቁ ያበቃል።

ለእነዚህ ሁለት ነጥቦች ምስጋና ይግባውና የእኛ ደህንነቱ የተጠበቀ የማሰማሪያ ስልተ ቀመር እንደዚህ ይመስላል።

1. ገንቢው አዲስ የኮድ ፓኬጅ ይገነባል (በእኛ ሁኔታ RPM ነው)፣ በገንቢ አካባቢ ውስጥ ይፈትነዋል፣ በደረጃ አካባቢ ውስጥ ይፈትነዋል፣ እና በደረጃ ማከማቻ ውስጥ ይተወዋል።
2. ገንቢው ስለ "ቅርሶች" ዝርዝር መግለጫ የያዘ የማሰማሪያ ተግባር ያዘጋጃል፤ ይህም የአዲሱ ፓኬጅ ስሪት፣ የአዲሱ ተግባር መግለጫ እና አስፈላጊ ከሆነ ሌሎች የማሰማሪያ ዝርዝሮችን ያካትታል።
3. የስርዓት አስተዳዳሪው ዝመናውን ያስጀምራል። የአንሲብል ፕሌይቡክን ያሂዳሉ፣ እሱም በተራው የሚከተሉትን ያደርጋል፡
   • አንድ ፓኬጅ ከመድረክ ማከማቻ ወስዶ በምርት ማከማቻው ውስጥ ያለውን የጥቅል ስሪት በእሱ ላይ በመመስረት ያዘምናል።
   • ለሚዘመነው አገልግሎት የኋላ መሸፈኛዎችን ዝርዝር ያመነጫል።
   • በ HAProxy ውስጥ የሚዘመነውን የመጀመሪያውን አገልግሎት ይዘጋል እና ሂደቱ እስኪጠናቀቅ ይጠብቃል። ለጥሩ መዘጋት ምስጋና ይግባውና ሁሉም የአሁኑ የደንበኛ ጥያቄዎች በተሳካ ሁኔታ መሟላታቸውን እናረጋግጣለን።
   • ኤፒአይ እና ሰራተኞቹ ሙሉ በሙሉ ከተቆሙ እና HAProxy ከጠፋ በኋላ ኮዱ ይዘምናል።
   • አኒሴል አገልግሎቶችን ይጀምራል።
   • ለእያንዳንዱ አገልግሎት፣ አስቀድሞ ከተገለጹ የቁልፍ ሙከራዎች ጋር አሃድ የሚፈትሹ የተወሰኑ "እጀታዎች" ይጎተታሉ። የአዲሱ ኮድ መሰረታዊ ማረጋገጫ ይከናወናል።
   • በቀደመው ደረጃ ምንም ስህተቶች ካልተገኙ፣ የኋላው ክፍል ገቢር ይሆናል።
   • ወደሚቀጥለው የኋላ ክፍል እንሸጋገር።
4. ሁሉም የኋላ ክንዶች ከተዘመኑ በኋላ ተግባራዊ ሙከራዎች ይካሄዳሉ። ከጎደሉ፣ ገንቢው የተተገበሩትን ማንኛውንም አዲስ ተግባር ይገመግማል።

ይህ ማሰማራቱን ያጠናቅቃል።

የአገልግሎት ዝማኔ ዑደት

አንድ ደንብ ባይኖረን ኖሮ ይህ ስርዓት አይሰራም ነበር። አሮጌውንም ሆነ አዲሶቹን ስሪቶች በአንድ ጊዜ እናስቀጥላለን። ከጅምሩ ጀምሮ በሶፍትዌር ልማት ወቅት በአገልግሎቱ የውሂብ ጎታ ላይ ለውጦች ቢደረጉም እንኳ የቀደመውን ኮድ እንደማይጥሱ እናረጋግጣለን። በዚህም ምክንያት የኮድ ቤዝ ቀስ በቀስ ይዘምናል።

መደምደሚያ

ስለ ስህተት መቋቋም በሚችል የድር አርክቴክቸር ላይ ሀሳቤን አካፍዬ፣ ቁልፍ ነጥቦቹን እንደገና መግለጽ እፈልጋለሁ፡

• አካላዊ የስህተት መቻቻል;
• የአውታረ መረብ ስህተት መቻቻል (ሚዛንሰሮች፣ BGP);
• ጥቅም ላይ የዋለውን እና የተገነባውን ሶፍትዌር የስህተት መቻቻል።

ሁላችሁም የተረጋጋ የስራ ሰዓት ይሁንላችሁ!

ምንጭ: hab.com