እራሱን የሚፈውስ አውታረ መረብ፡ የፍሎው ሌብል አስማት እና በሊኑክስ ከርነል ዙሪያ ያለው መርማሪ። የ Yandex ሪፖርት

ዘመናዊ የመረጃ ማዕከላት በተለያዩ የክትትል ዓይነቶች የተሸፈኑ በመቶዎች የሚቆጠሩ ንቁ መሣሪያዎች አሏቸው። ነገር ግን በእጁ ውስጥ ፍጹም ክትትል ያለው ፍጹም መሐንዲስ እንኳን ለአውታረ መረብ ብልሽት በጥቂት ደቂቃዎች ውስጥ በትክክል ምላሽ መስጠት ይችላል። በNext Hop 2020 ኮንፈረንስ ላይ ባቀረበው ዘገባ፣ ልዩ ባህሪ ያለው የዳታ ሴንተር ኔትወርክ ዲዛይን ዘዴን አቅርቤያለሁ - የመረጃ ማእከሉ እራሱን በሚሊሰከንዶች ይፈውሳል። ይበልጥ በትክክል ፣ መሐንዲሱ በተረጋጋ ሁኔታ ችግሩን ያስተካክላሉ ፣ አገልግሎቶቹ በቀላሉ አያስተውሉም።

- ለመጀመር ፣ ምናልባት ስለ ዘመናዊ የዲሲ አወቃቀር ለማያውቁ ፣ በትክክል ዝርዝር መግቢያ እሰጣለሁ።


ለብዙ የኔትወርክ መሐንዲሶች የውሂብ ማዕከል አውታረመረብ የሚጀምረው በ ToR, በመደርደሪያው ውስጥ ባለው መቀየሪያ ነው. ቶአር ብዙውን ጊዜ ሁለት ዓይነት ማገናኛዎች አሉት። ትንንሾቹ ወደ ሰርቨሮች ይሄዳሉ, ሌሎች - N ጊዜዎች ብዙ ናቸው - ወደ መጀመሪያው ደረጃ እሾህ ይሂዱ, ማለትም ወደ አገናኞች ይሂዱ. አፕሊኬሽኖች ብዙውን ጊዜ እንደ እኩል ይቆጠራሉ፣ እና በአገናኞች መካከል ያለው ትራፊክ በ5-tuple hash ላይ በመመስረት ሚዛናዊ ነው፣ እሱም ፕሮቶ፣ src_ip፣ dst_ip፣ src_port፣ dst_portን ያካትታል። እዚህ ምንም አስገራሚ ነገሮች የሉም.


በመቀጠል የአውሮፕላኖቹ አርክቴክቸር ምን ይመስላል? የአንደኛው ደረጃ አከርካሪዎች እርስ በርስ የተያያዙ አይደሉም, ነገር ግን በሱፐርስፒኖች አማካኝነት የተገናኙ ናቸው. ፊደል X superspins ተጠያቂ ይሆናል, ይህ ማለት ይቻላል እንደ መስቀል-ግንኙነት ነው.


እና በሌላ በኩል, ቶሪ ከመጀመሪያው ደረጃ ከሁሉም አከርካሪዎች ጋር የተገናኘ መሆኑን ግልጽ ነው. በዚህ ምስል ውስጥ ምን አስፈላጊ ነው? በመደርደሪያው ውስጥ መስተጋብር ካለን መስተጋብር በእርግጥ በቶር በኩል ያልፋል። ግንኙነቱ ወደ ሞጁሉ ውስጥ ከገባ ፣ ከዚያ ግንኙነቱ በመጀመሪያ ደረጃ አከርካሪው ውስጥ ያልፋል። ግንኙነቱ መካከለኛ ከሆነ - እዚህ ፣ ToR 1 እና ToR 2 - ከዚያ ግንኙነቱ በሁለቱም የመጀመሪያ እና ሁለተኛ ደረጃዎች አከርካሪዎች ውስጥ ያልፋል።


በንድፈ ሀሳብ, እንዲህ ዓይነቱ አርክቴክቸር በቀላሉ ሊሰፋ የሚችል ነው. የወደብ አቅም ካለን፣ በመረጃ ማዕከሉ ውስጥ ያለው የመጠባበቂያ ቦታ እና አስቀድሞ የተቀመጠ ፋይበር ካለን የአውሮፕላኖቹ ብዛት ሁልጊዜ ሊጨምር ይችላል በዚህም የስርዓቱን አጠቃላይ አቅም ይጨምራል። በወረቀት ላይ, ይህን ለማድረግ በጣም ቀላል ነው. በእውነተኛ ህይወት ውስጥ እንደዚያ ይሆናል. የዛሬው ታሪክ ግን ስለዚህ ጉዳይ አይደለም።


ትክክለኛ መደምደሚያዎች እንዲደረጉ እፈልጋለሁ. በመረጃ ማእከል ውስጥ ብዙ መንገዶች አሉን። በቅድመ ሁኔታ ነጻ ናቸው። በመረጃ ማእከል ውስጥ አንዱ መንገድ በቶር ውስጥ ብቻ ነው የሚቻለው። በሞጁሉ ውስጥ ልክ እንደ አውሮፕላኖች ቁጥር ተመሳሳይ የመንገዶች ቁጥር አለን. በሞጁሎች መካከል ያሉት የመንገዶች ብዛት ከአውሮፕላኖች ብዛት እና በእያንዳንዱ አውሮፕላን ውስጥ ካለው የሱፐርስፒኖች ብዛት ጋር እኩል ነው። ይበልጥ ግልጽ ለማድረግ, ልኬቱን ለመሰማት, ለአንዱ የ Yandex የውሂብ ማእከሎች ትክክለኛ የሆኑትን ቁጥሮች እሰጣለሁ.


ስምንት አውሮፕላኖች አሉ, እያንዳንዱ አውሮፕላን 32 superspins አለው. በውጤቱም ፣ በሞጁሉ ውስጥ ስምንት መንገዶች መኖራቸውን ያሳያል ፣ እና ከሞዱል መስተጋብር ጋር ቀድሞውኑ 256 የሚሆኑት አሉ።

ማለትም ፣ Cookbookን እያዘጋጀን ከሆነ ፣ እራሳቸውን የሚፈውሱ ጥፋቶችን የሚቋቋሙ የመረጃ ማዕከሎችን እንዴት መገንባት እንደሚችሉ ለመማር እየሞከርን ከሆነ ፣ ከዚያ የፕላን አርክቴክቸር ትክክለኛ ምርጫ ነው። የመለጠጥ ችግርን ለመፍታት ያስችልዎታል, እና በንድፈ ሀሳብ ቀላል ነው. ብዙ ገለልተኛ መንገዶች አሉ። ጥያቄው ይቀራል-እንዲህ ዓይነቱ አርክቴክቸር ውድቀቶችን እንዴት ይተርፋል? የተለያዩ ብልሽቶች አሉ። እና ስለዚህ ጉዳይ አሁን እንነጋገራለን.


ከኛ ሱፐርስፒኖች አንዱ ይታመም. እዚህ ወደ ሁለት አውሮፕላኖች አርክቴክቸር ተመለስኩ። እነሱን እንደ ምሳሌ እንይዛቸዋለን ምክንያቱም እዚህ ምን እየተደረገ እንዳለ በጥቂት ተንቀሳቃሽ ክፍሎች በቀላሉ ማየት ቀላል ይሆናል። X11 ይታመም. ይህ በመረጃ ማእከሎች ውስጥ የሚኖሩ አገልግሎቶችን እንዴት ይነካል? ብዙ የሚወሰነው ውድቀቱ እንዴት እንደሚመስል ላይ ነው።


አለመሳካቱ ጥሩ ከሆነ, በተመሳሳይ የ BFD አውቶማቲክ ደረጃ ላይ ተይዟል, አውቶማቲክ የችግር መገጣጠሚያዎችን በደስታ ያስቀምጣል እና ችግሩን ይለያል, ከዚያ ሁሉም ነገር ጥሩ ነው. ብዙ መንገዶች አሉን ፣ ትራፊክ ወዲያውኑ ወደ አማራጭ መንገዶች ይዛወራል ፣ እና አገልግሎቶቹ ምንም አያስተውሉም። ይህ ጥሩ ሁኔታ ነው።


አንድ መጥፎ ሁኔታ የማያቋርጥ ኪሳራ ካለብን እና አውቶሜሽኑ ችግሩን አያስተውለውም። ይህ ማመልከቻውን እንዴት እንደሚጎዳ ለመረዳት የTCP ፕሮቶኮል እንዴት እንደሚሰራ ለመወያየት ትንሽ ጊዜ ማሳለፍ አለብን።


በዚህ መረጃ ማንንም እንደማልደነግጥ ተስፋ አደርጋለሁ፡ TCP የመጨባበጥ ፕሮቶኮል ነው። ያም ማለት በጣም ቀላል በሆነው ጉዳይ ላኪው ሁለት ፓኬቶችን ይልካል እና በእነሱ ላይ ድምር ምልክት ይቀበላል: "ሁለት ፓኬቶችን ተቀብያለሁ."


ከዚያ በኋላ, ሁለት ተጨማሪ ፓኬቶችን ይልካል, እና ሁኔታው ​​ይደገማል. ስለ አንዳንድ ማቅለል አስቀድሜ ይቅርታ እጠይቃለሁ. መስኮቱ (በበረራ ውስጥ ያሉት የፓኬቶች ብዛት) ሁለት ከሆነ ይህ ሁኔታ ትክክል ነው። በእርግጥ ይህ በአጠቃላይ የግድ አይደለም. ነገር ግን የፓኬት ማስተላለፊያ አውድ በመስኮቱ መጠን አይነካም.


ጥቅል 3 ብንጠፋ ምን ይከሰታል? በዚህ አጋጣሚ ተቀባዩ ፓኬት 1፣ 2 እና 4 ይቀበላል። እና “ታውቃለህ፣ ሶስት መጥተዋል፣ መሃል ግን ጠፍቶ ነበር” የሚለውን የሳክ አማራጭ በመጠቀም ለላኪው በግልፅ ያሳውቃል። "Ack 2, SACK 4" ይላል።


ላኪው በዚህ ጊዜ ያለ ምንም ችግር የጠፋውን ፓኬት በትክክል ይደግማል።


ነገር ግን በመስኮቱ ውስጥ ያለው የመጨረሻው ፓኬት ከጠፋ, ሁኔታው ​​​​በጣም የተለየ ይመስላል.

ተቀባዩ የመጀመሪያዎቹን ሶስት እሽጎች ይቀበላል እና በመጀመሪያ መጠበቅ ይጀምራል. በሊኑክስ ከርነል ቲሲፒ ቁልል ውስጥ ለተደረጉ አንዳንድ ማሻሻያዎች ምስጋና ይግባውና በባንዲራዎቹ ውስጥ ይህ የመጨረሻው ፓኬት ወይም ሌላ ነገር እንደሆነ ግልጽ ምልክት ከሌለ በስተቀር የተጣመረ ፓኬት ይጠብቃል። የዘገየው ACK ጊዜ ማብቂያ እስኪያልቅ ድረስ ይጠብቃል እና ከዚያ ለመጀመሪያዎቹ ሶስት እሽጎች እውቅና ይልካል። አሁን ግን ላኪው ይጠብቃል። አራተኛው ፓኬጅ ጠፍቶ ወይም ሊመጣ እንደሆነ አያውቅም። እና ኔትወርኩን ከመጠን በላይ ላለመጫን, ፓኬቱ እንደጠፋ ወይም የ RTO ጊዜ ማብቂያው የሚያበቃበትን ግልጽ ምልክት ለመጠበቅ ይሞክራል.


የ RTO ጊዜ ማብቂያ ምንድን ነው? ይህ በTCP ቁልል እና አንዳንድ ቋሚ የተሰላው ከ RTT ከፍተኛው ነው። ይህ ቋሚ ምንድን ነው, አሁን እንነጋገራለን.


ግን እንደገና እድለኛ ካልሆንን እና አራተኛው ፓኬት እንደገና ከጠፋ RTO በእጥፍ ይጨምራል። ያም ማለት፣ እያንዳንዱ ያልተሳካ ሙከራ ጊዜ ማብቂያው በእጥፍ ይጨምራል።


አሁን ይህ መሠረት ምን እኩል እንደሆነ እንይ. በነባሪ፣ ዝቅተኛው RTO 200ms ነው። ይህ ለመረጃ እሽጎች ዝቅተኛው RTO ነው። ለ SYN ፓኬቶች፣ የተለየ ነው፣ 1 ሰከንድ። እንደሚመለከቱት፣ እሽጎችን እንደገና ለመላክ የመጀመሪያው ሙከራ እንኳን በመረጃ ማእከሉ ውስጥ ካለው RTT 100 እጥፍ ይረዝማል።


አሁን ወደ ሁኔታችን እንመለስ። በአገልግሎቱ ላይ ምን እየሆነ ነው? አገልግሎቱ ፓኬቶችን ማጣት ይጀምራል. አገልግሎቱ መጀመሪያ ላይ እድለኛ ይሁን እና በመስኮቱ መካከል የሆነ ነገር ያጣል, ከዚያም ከረጢት ይቀበላል, የጠፉትን እሽጎች እንደገና ይልካል.


ግን መጥፎ ዕድል ከደገመ RTO አለን ማለት ነው። እዚህ ምን አስፈላጊ ነው? አዎ, በአውታረ መረቡ ውስጥ ብዙ መንገዶች አሉን. ነገር ግን የአንድ የተወሰነ TCP ግንኙነት የTCP ትራፊክ በተሰበረ ቁልል ውስጥ ማለፍ ይቀጥላል። የፓኬት መጥፋት አስማታችን X11 በራሱ ካልወጣ ችግር ወደሌለባቸው አካባቢዎች የትራፊክ ፍሰትን አያመጣም። በተመሳሳዩ በተሰበረ ቁልል ውስጥ ፓኬት ለማቅረብ እየሞከርን ነው። ይህ ወደ ካስካዲንግ አለመሳካት ያመራል፡ የዳታ ሴንተር በይነተገናኝ አፕሊኬሽኖች ስብስብ ነው፣ እና የእነዚህ ሁሉ አፕሊኬሽኖች አንዳንድ TCP ግንኙነቶች ማሽቆልቆል ይጀምራሉ - ምክንያቱም ሱፐርስፒን በዲሲ ውስጥ ያሉትን ሁሉንም መተግበሪያዎች ይጎዳል። እንደ አባባል: ፈረስ ጫማ ካላደረጉ, ፈረሱ ይንከራተታል; ፈረሱ አንገተ - ሪፖርቱ አልደረሰም; መልእክቱ አልደረሰም - ጦርነቱን ተሸንፈዋል. እዚህ ብቻ ቆጠራው ችግሩ ከተፈጠረበት ጊዜ አንስቶ አገልግሎቶቹ መሰማት እስከሚጀምሩበት ደረጃ ድረስ ለሴኮንዶች ይሄዳል። ይህ ማለት ተጠቃሚዎች የሆነ ቦታ ላይ የሆነ ነገር ላይቀበሉ ይችላሉ ማለት ነው።


እርስ በርስ የሚደጋገፉ ሁለት ጥንታዊ መፍትሄዎች አሉ. የመጀመሪያው ገለባ ለመዘርጋት እና ችግሩን በዚህ መልኩ ለመፍታት የሚጥሩ አገልግሎቶች ናቸው፡- “በTCP ቁልል ውስጥ የሆነ ነገር እናስተካክል። እና የመተግበሪያ ደረጃ ጊዜያቶች ወይም ረጅም ጊዜ የሚቆዩ የTCP ክፍለ ጊዜዎችን ከውስጥ የጤና ፍተሻዎች ጋር እናድርግ። ችግሩ እንዲህ ያሉ መፍትሄዎች: ሀ) ጨርሶ አይመዘኑም; ለ) በጣም ደካማ ተፈትኗል. ማለትም ፣ አገልግሎቱ በአጋጣሚ የ TCP ቁልል የተሻለ እንዲሆን ቢያዋቅርም ፣ በመጀመሪያ ፣ ይህ በሁሉም መተግበሪያዎች እና በሁሉም የመረጃ ማእከሎች ላይ ተፈፃሚ አይሆንም ፣ እና ሁለተኛ ፣ ምናልባትም ፣ በትክክል ምን እንደተሰራ እና ምን እንደሆነ አይረዳም። አይደለም. ያም ማለት, ይሰራል, ነገር ግን በደንብ አይሰራም እና አይመዘንም. እና የኔትወርክ ችግር ካለ ተጠያቂው ማነው? በእርግጥ NOC. NOC ምን ያደርጋል?

ብዙ አገልግሎቶች በ NOC ውስጥ ሥራ እንደዚህ ያለ ነገር እንደሚሄድ ያምናሉ። ግን እውነቱን ለመናገር ብቻ ሳይሆን.


በጥንታዊው እቅድ ውስጥ NOC ብዙ ክትትልን በማዳበር ላይ ይገኛል. እነዚህ ሁለቱም የጥቁር ሣጥን ቁጥጥር እና የነጭ ሳጥን ክትትል ናቸው። ስለ ጥቁር ሳጥን-የአከርካሪ አጥንት ክትትል ምሳሌ ተናገሩ አሌክሳንደር ክሊሜንኮ ባለፈው ቀጣይ ሆፕ. በነገራችን ላይ ይህ ክትትል ይሠራል. ግን ፍጹም ክትትል እንኳን የጊዜ መዘግየት ይኖረዋል። አብዛኛውን ጊዜ ብዙ ደቂቃዎች ነው. ሥራ ከጀመረ በኋላ በሥራ ላይ ያሉት መሐንዲሶች ሥራውን እንደገና ለመፈተሽ፣ ችግሩን አካባቢያዊ ለማድረግ እና የችግሩን አካባቢ ለማጥፋት ጊዜ ያስፈልጋቸዋል። ያም ማለት በጥሩ ሁኔታ ላይ የችግሩ ሕክምና 5 ደቂቃ ይወስዳል, በአስከፊው 20 ደቂቃዎች ውስጥ, ኪሳራዎቹ የት እንደሚገኙ ወዲያውኑ ግልጽ ካልሆነ. በዚህ ጊዜ ሁሉ - 5 ወይም 20 ደቂቃዎች - አገልግሎታችን መጎዳቱን እንደሚቀጥል ግልጽ ነው, ይህ ምናልባት ጥሩ አይደለም.


ምን መቀበል ይፈልጋሉ? ብዙ መንገዶች አሉን። እና ችግሮች የሚከሰቱት በትክክል ያልታደሉ የTCP ፍሰቶች ተመሳሳይ መንገድ መጠቀማቸውን ስለሚቀጥሉ ነው። በአንድ TCP ግንኙነት ውስጥ ብዙ መንገዶችን እንድንጠቀም የሚያስችለን ነገር እንፈልጋለን። መፍትሄ ያለን ይመስላል። TCP አለ, እሱም እንዲሁ ተብሎ የሚጠራው - multipath TCP, ማለትም, TCP ለብዙ መንገዶች. እውነት ነው, የተሰራው ሙሉ ለሙሉ የተለየ ተግባር ነው - በርካታ የአውታረ መረብ መሳሪያዎች ላሏቸው ስማርትፎኖች. ዝውውሩን ከፍ ለማድረግ ወይም የመጀመሪያ ደረጃ / የመጠባበቂያ ሁነታን ለመስራት ለመተግበሪያው ብዙ ክሮች (ክፍለ-ጊዜዎች) በግልፅ የሚፈጥር እና ካልተሳካ በመካከላቸው እንዲቀያየሩ የሚያስችል ዘዴ ተፈጠረ። ወይም፣ እንዳልኩት የመተላለፊያ ይዘትን ከፍ አድርግ።

ግን እዚህ አንድ ልዩነት አለ. ምን እንደሆነ ለመረዳት ዥረቶች እንዴት እንደሚዋቀሩ ማየት አለብን።


ክሮች በቅደም ተከተል ተቀምጠዋል. የመጀመሪያው ዥረት መጀመሪያ ተጭኗል። ከዚያ ተከታይ ፍሰቶች የሚዘጋጁት ቀደም ሲል በዚያ ክር ውስጥ የተስማማውን ኩኪ በመጠቀም ነው። እና ችግሩ እዚህ አለ።


ችግሩ የመጀመሪያው ክር ካልተጫነ, ሁለተኛው እና ሦስተኛው ክሮች በጭራሽ አይመጡም. ማለትም፣ ባለብዙ መንገድ TCP የ SYN ፓኬት መጥፋት በመጀመሪያው ዥረት ላይ አይፈታም። እና SYN ከጠፋ፣ ባለብዙ መንገድ TCP መደበኛ TCP ይሆናል። ስለዚህ በመረጃ ማእከል አካባቢ በፋብሪካ ውስጥ ያለውን የኪሳራ ችግር ለመፍታት እና ውድቀት በሚከሰትበት ጊዜ ብዙ መንገዶችን እንዴት መጠቀም እንዳለብን ለመማር አይረዳንም።


ምን ሊረዳን ይችላል? አንዳንዶቻችሁ በቀጣይ ታሪካችን ውስጥ ያለው ጠቃሚ መስክ የIPv6 ፍሰት መለያ አርዕስት መስክ እንደሚሆን ከስሙ ገምታችኋል። በእርግጥ ይህ በ v6 ውስጥ የሚታየው መስክ ነው, በ v4 ውስጥ አይደለም, 20 ቢት ይወስዳል, እና ስለ አጠቃቀሙ ለረጅም ጊዜ ውዝግቦች ነበሩ. ይህ በጣም አስደሳች ነው - አለመግባባቶች ነበሩ ፣ በ RFC ማዕቀፍ ውስጥ አንድ ነገር ተስተካክሏል ፣ እና በተመሳሳይ ጊዜ ፣ ​​በየትኛውም ቦታ ያልተመዘገበ በሊኑክስ ከርነል ውስጥ ትግበራ ታየ።


በትንሽ ምርመራ እንድትተባበሩኝ እመክራለሁ። ባለፉት ጥቂት አመታት በሊኑክስ ከርነል ውስጥ ምን እየሆነ እንዳለ እንይ።

2014 ዓ.ም. የአንድ ትልቅ እና ታዋቂ ኩባንያ መሐንዲስ የሊኑክስ ከርነል ተግባራዊነት ላይ የፍሰት መለያው በሶኬት ሃሽ ላይ ያለውን ጥገኛነት ይጨምራል። እዚህ ምን ለማስተካከል እየሞከሩ ነው? ይህ በሚከተለው ጉዳይ ላይ ከተወያየው RFC 6438 ጋር የተያያዘ ነው። በመረጃ ማእከሉ ውስጥ, IPv4 ብዙውን ጊዜ በ IPv6 ፓኬቶች ውስጥ ተቀርጿል, ምክንያቱም ፋብሪካው ራሱ IPv6 ነው, ነገር ግን IPv4 በሆነ መንገድ መሰጠት አለበት. ወደ TCP ወይም UDP ለመድረስ እና src_ports፣ dst_portsን ለማግኘት በሁለት የአይፒ አርዕስቶች ስር መመልከት የማይችሉ ማብሪያና ማጥፊያዎች ለረጅም ጊዜ ችግሮች ነበሩ። የመጀመሪያዎቹን ሁለቱን የአይፒ አርዕስቶች ከተመለከቱ ፣ hash ለመስተካከል ተቃርቧል። ይህንን ለማስቀረት፣ የዚህን የታሸገ ትራፊክ ማመጣጠን በትክክል እንዲሰራ፣ ከ5-tuple የታሸገ ፓኬት ወደ ፍሰት መለያ መስክ እሴት ላይ ሃሽ ለመጨመር ታቅዶ ነበር። በግምት ለሌሎች የማሸግ ዘዴዎች፣ ለ UDP፣ ለ GRE፣ በኋለኛው የ GRE ቁልፍ መስክ ጥቅም ላይ ውሏል። አንድ መንገድ ወይም ሌላ, እዚህ ያሉት ግቦች ግልጽ ናቸው. እና ቢያንስ በዚያ ጊዜ ጠቃሚ ነበሩ.

እ.ኤ.አ. በ 2015 ፣ ከተመሳሳዩ የተከበረ መሐንዲስ አዲስ ንጣፍ ይመጣል። እሱ በጣም የሚስብ ነው። የሚከተለውን ይላል - አሉታዊ የማዘዋወር ክስተት ሲከሰት ሃሽውን በዘፈቀደ እናደርገዋለን። አሉታዊ የማዞሪያ ክስተት ምንድን ነው? ይህ ቀደም ብለን የተነጋገርነው RTO ነው, ማለትም, የዊንዶው ጅራት ማጣት በእውነቱ አሉታዊ ክስተት ነው. እውነት ነው, ምን እንደሆነ ለመገመት በአንጻራዊነት አስቸጋሪ ነው.

2016, ሌላ የተከበረ ኩባንያ, እንዲሁም ትልቅ. የመጨረሻዎቹን ክራንች ይተነትናል እና ከዚህ ቀደም በዘፈቀደ ያደረግነው ሃሽ አሁን በእያንዳንዱ የSYN ዳግም ማስተላለፊያ ላይ እና ከእያንዳንዱ የRTO ጊዜ ማብቂያ በኋላ እንዲቀየር ያደርገዋል። እና በዚህ ደብዳቤ ውስጥ, ለመጀመሪያ እና ለመጨረሻ ጊዜ, የመጨረሻው ግብ ድምጾች - መጥፋት ወይም ሰርጦች መጫን ክስተት ውስጥ ትራፊክ በርካታ መንገዶችን በመጠቀም, ለስላሳ rerouting አጋጣሚ እንዳለው ለማረጋገጥ. እርግጥ ነው, ከዚያ በኋላ ብዙ ህትመቶች ነበሩ, በቀላሉ ሊያገኟቸው ይችላሉ.

ምንም እንኳን አይሆንም፣ አይችሉም፣ ምክንያቱም በዚህ ርዕስ ላይ አንድም እትም የለም። ግን እናውቃለን!

እና የተደረገውን ሙሉ በሙሉ ካልተረዳህ አሁን እነግራችኋለሁ።


ምን ተሰራ፣ ምን አይነት ተግባር ወደ ሊኑክስ ከርነል ተጨምሯል? txhash ከእያንዳንዱ RTO ክስተት በኋላ ወደ የዘፈቀደ እሴት ይቀየራል። ይህ ተመሳሳይ አሉታዊ የማዞሪያ ውጤት ነው. ሃሽ በዚህ txhash ላይ የሚመረኮዝ ሲሆን የፍሰት መለያው በ skb hash ላይ ይወሰናል። እዚህ በተግባሮቹ ላይ አንዳንድ ስሌቶች አሉ, ሁሉም ዝርዝሮች በአንድ ስላይድ ላይ ሊቀመጡ አይችሉም. የማወቅ ጉጉት ያለው ካለ በከርነል ኮድ ውስጥ ገብተህ ማረጋገጥ ትችላለህ።

እዚህ ምን አስፈላጊ ነው? የፍሰት መለያ መስክ ዋጋ ከእያንዳንዱ RTO በኋላ ወደ የዘፈቀደ ቁጥር ይቀየራል። ይህ እድለኛ ያልሆነውን የTCP ዥረታችንን እንዴት ይነካዋል?


በSACK ጉዳይ፣ የታወቀ የጠፋ ፓኬት እንደገና ለመላክ እየሞከርን ስለሆነ ምንም አልተለወጠም። እስካሁን ድረስ ጥሩ.


ነገር ግን በ RTO ጉዳይ፣ በToR ላይ ባለው የሃሽ ተግባር ላይ የፍሰት መለያ ካከልን ፣ ትራፊክ የተለየ መንገድ ሊወስድ ይችላል። እና ብዙ አውሮፕላኖች, በአንድ የተወሰነ መሳሪያ ላይ በአደጋ ምክንያት ያልተጎዳ መንገድ የማግኘት እድሉ ከፍተኛ ነው.


አንድ ችግር ይቀራል - RTO. ሌላ መንገድ, በእርግጥ, ተገኝቷል, ግን ብዙ ጊዜ በእሱ ላይ ይውላል. 200ms ብዙ ነው። አንድ ሰከንድ በአጠቃላይ ዱር ነው. ቀደም ሲል አገልግሎቶችን ስለሚያዋቅሩ የጊዜ ማብቂያዎች ተናግሬ ነበር። ስለዚህ, አንድ ሰከንድ አብዛኛውን ጊዜ አገልግሎትን በአፕሊኬሽን ደረጃ የሚያዘጋጅ የጊዜ ማብቂያ ነው, እና በዚህ ውስጥ አገልግሎቱ በአንጻራዊነት ትክክል ይሆናል. ከዚህም በላይ፣ እደግመዋለሁ፣ በዘመናዊ የመረጃ ማዕከል ውስጥ ያለው ትክክለኛው RTT ወደ 1 ሚሊሰከንድ አካባቢ ነው።


ስለ RTO ጊዜ ማብቂያ ምን ማድረግ ይቻላል? የውሂብ እሽጎች ቢጠፉ ለ RTO ኃላፊነት ያለው የጊዜ ማብቂያ በአንፃራዊነት በቀላሉ ከተጠቃሚ ቦታ ሊዋቀር ይችላል፡ የአይፒ መገልገያ አለ፣ እና አንዱ ግቤቶቹ ተመሳሳይ rto_min ይዟል። ያንን ከግምት ውስጥ በማስገባት ፣ በእርግጥ ፣ RTO ን በዓለም አቀፍ ደረጃ ማዞር ያስፈልግዎታል ፣ ግን ለተሰጡት ቅድመ-ቅጥያዎች ፣ እንዲህ ዓይነቱ ዘዴ በጣም የሚሰራ ይመስላል።


እውነት ነው፣ በSYN_RTO ሁሉም ነገር በተወሰነ ደረጃ የከፋ ነው። በተፈጥሮ የተቸነከረ ነው. እሴቱ በዋና ውስጥ ተስተካክሏል - 1 ሰከንድ, እና ያ ነው. ከተጠቃሚ ቦታ ሊደርሱበት አይችሉም። አንድ መንገድ ብቻ ነው.


eBPF ለማዳን ይመጣል። በቀላል አነጋገር እነዚህ ትናንሽ የ C ፕሮግራሞች ናቸው ። በከርነል ቁልል እና በ TCP ቁልል አፈፃፀም ውስጥ በተለያዩ ቦታዎች ወደ መንጠቆዎች ሊገቡ ይችላሉ ፣ በዚህም እጅግ በጣም ብዙ ቅንብሮችን መለወጥ ይችላሉ። በአጠቃላይ eBPF የረጅም ጊዜ አዝማሚያ ነው። በደርዘኖች የሚቆጠሩ አዳዲስ የ sysctl መለኪያዎችን ከመቁረጥ እና የአይፒ መገልገያውን ከማስፋፋት ይልቅ እንቅስቃሴው በ eBPF አቅጣጫ እና ተግባራቱን በማስፋፋት ላይ ነው። በ eBPF፣ የመጨናነቅ መቆጣጠሪያዎችን እና ሌሎች የተለያዩ የTCP ቅንብሮችን በተለዋዋጭነት መቀየር ይችላሉ።


ግን በእሱ እርዳታ የ SYN_RTO እሴቶችን ማጣመም ለእኛ አስፈላጊ ነው። እና በይፋ የተለጠፈ ምሳሌ አለ፡- https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. እዚህ ምን ይደረጋል? ምሳሌው እየሰራ ነው, ግን በራሱ በጣም ሻካራ ነው. እዚህ እንደታሰበው በመረጃ ማእከሉ ውስጥ የመጀመሪያዎቹን 44 ቢት እናነፃፅራለን ፣ እነሱ የሚዛመዱ ከሆነ ፣ ከዚያ እኛ እራሳችንን በዲሲ ውስጥ እናገኛለን። እና በዚህ አጋጣሚ፣ የSYN_RTO ጊዜ ማብቂያ ዋጋን ወደ 4 ሚሴ እንለውጣለን። ተመሳሳዩን ተግባር የበለጠ በሚያምር ሁኔታ ማከናወን ይቻላል. ግን ይህ ቀላል ምሳሌ ሀ) የሚቻለውን ያሳያል; ለ) በአንጻራዊነት ቀላል.

አስቀድመን ምን እናውቃለን? የፕላን አርክቴክቸር ልኬትን የሚፈቅድ በመሆኑ፣ የፍሰት መለያውን በቶአር ላይ ስንከፍት እና ችግር ባለባቸው አካባቢዎች የመፍሰስ እድል ስናገኝ ለእኛ እጅግ በጣም ጠቃሚ ይሆናል። RTO እና SYN-RTO እሴቶችን ዝቅ ለማድረግ በጣም ጥሩው መንገድ eBPF ፕሮግራሞችን መጠቀም ነው። ጥያቄው ይቀራል፡ ለማመጣጠን የፍሰት መለያውን መጠቀም ደህንነቱ የተጠበቀ ነው? እና እዚህ አንድ ልዩነት አለ.


በኔትወርኩ ላይ በማንኛውም ካሴት ውስጥ የሚኖር አገልግሎት አለህ እንበል። እንደ አለመታደል ሆኖ ስለማንኛውም ፊልም በዝርዝር ለመናገር ጊዜ የለኝም ነገር ግን የተለያዩ አካላዊ አገልጋዮች በተመሳሳይ አይፒ አድራሻ የሚገኙበት የተከፋፈለ አገልግሎት ነው። እና እዚህ ሊኖር የሚችል ችግር አለ: የ RTO ክስተት በፋብሪካው ውስጥ ሲያልፍ ብቻ ሳይሆን ሊከሰት ይችላል. በToR ቋት ደረጃም ሊከሰት ይችላል፡ የገባ ክስተት ሲከሰት አስተናጋጁ የሆነ ነገር ሲፈስ በአስተናጋጁ ላይ እንኳን ሊከሰት ይችላል። የ RTO ክስተት ሲከሰት እና የፍሰት መለያውን ይለውጣል. በዚህ አጋጣሚ ትራፊኩ ወደ ሌላ ማንኛውም የተላለፈ ምሳሌ ሊሄድ ይችላል። የስቴት ማንኛውም ካስት ነው እንበል፣ የግንኙነት ሁኔታ ይዟል - L3 Balancer ወይም ሌላ አገልግሎት ሊሆን ይችላል። ከዚያ ችግር ይፈጠራል, ምክንያቱም ከ RTO በኋላ, የ TCP ግንኙነት በአገልጋዩ ላይ ይደርሳል, ስለዚህ ስለ TCP ግንኙነት ምንም የሚያውቀው ነገር የለም. እና በየትኛዉም ካስት አገልጋዮች መካከል የስቴት መጋራት ከሌለን እንደዚህ አይነት ትራፊክ ይወድቃል እና የTCP ግንኙነቱ ይቋረጣል።


እዚህ ምን ሊደረግ ይችላል? ቁጥጥር በሚደረግበት አካባቢ፣ የፍሰት መለያ ማመጣጠን በሚያነቁበት፣ ወደ ማንኛቸውም የሚተላለፉ አገልጋዮችን ሲደርሱ የፍሰት መለያውን ዋጋ ማስተካከል ያስፈልግዎታል። ቀላሉ መንገድ በተመሳሳይ eBPF ፕሮግራም በኩል ማድረግ ነው። ግን እዚህ አንድ በጣም አስፈላጊ ነጥብ አለ - የመረጃ ማእከል አውታረመረብ ካልሰሩ ምን ማድረግ አለብዎት ፣ ግን የቴሌኮም ኦፕሬተር ከሆኑ? ይህ የእርስዎም ችግር ነው፡ ከተወሰኑ የጁኒፐር እና የአሪስታ ስሪቶች ጀምሮ የፍሰት መለያውን በሃሽ ተግባር ውስጥ በነባሪነት ያካትታሉ - እውነቱን ለመናገር እኔ ባልገባኝ ምክንያት። ይህ በአውታረ መረብዎ ውስጥ ከሚሄዱ ተጠቃሚዎች የ TCP ግንኙነቶችን እንዲያቋርጡ ሊያደርግዎት ይችላል። ስለዚህ የራውተርዎን መቼቶች በዚህ ቦታ እንዲፈትሹ በጣም እመክራለሁ።

አንድ መንገድ ወይም ሌላ, ወደ ሙከራዎች ለመሄድ ዝግጁ መሆናችንን ለእኔ ይመስላል.


የፍሰት መለያውን በቶአር ላይ ስንከፍት የወኪሉን eBPF ስናዘጋጅ፣ አሁን በአስተናጋጆች ላይ ይኖራል፣ ቀጣዩን ትልቅ ውድቀት ለመጠበቅ ሳይሆን ቁጥጥር የሚደረግበት ፍንዳታ ለማካሄድ ወስነናል። አራት አገናኞች ያለውን ቶአር ወስደን በአንደኛው ላይ ጠብታዎችን አደረግን። አንድ ደንብ አውጥተዋል, አሉ - አሁን ሁሉንም እሽጎች እያጡ ነው. በግራ በኩል እንደሚታየው፣ ወደ 75% ዝቅ ያለ፣ ማለትም፣ 25% ፓኬቶች የጠፉ የፔኬት ክትትል አለን። በቀኝ በኩል ከዚህ ቶር ጀርባ የሚኖሩ የአገልግሎት ግራፎች አሉ። በእውነቱ፣ እነዚህ በመደርደሪያው ውስጥ ካሉ አገልጋዮች ጋር የመገጣጠሚያዎች የትራፊክ ግራፎች ናቸው። እንደምታየው፣ ወደ ታች ዝቅ ብለው ሰመጡ። ለምን ዝቅ ብለው ሰመጡ - በ 25% ሳይሆን በአንዳንድ ሁኔታዎች 3-4 ጊዜ? የ TCP ግንኙነቱ እድለኛ ካልሆነ በተሰበረው በይነገጽ በኩል ለመድረስ መሞከሩን ይቀጥላል። ይህ በዲሲ ውስጥ ባለው የአገልግሎቱ ዓይነተኛ ባህሪ ተባብሷል - ለአንድ ተጠቃሚ ጥያቄ N የውስጣዊ አገልግሎቶች ጥያቄዎች ይፈጠራሉ እና ምላሹ ለተጠቃሚው ይሄዳል ፣ ሁሉም የመረጃ ምንጮች ምላሽ ሲሰጡ ወይም ጊዜ ማብቂያ በሚነሳበት ጊዜ። አሁንም መዋቀር ያለበት የመተግበሪያ ደረጃ። ያም ማለት ሁሉም ነገር በጣም በጣም መጥፎ ነው.


አሁን ተመሳሳይ ሙከራ፣ ነገር ግን በፍሰት መለያው ነቅቷል። እንደሚመለከቱት፣ በግራ በኩል፣ የእኛ የቡድን ክትትል በተመሳሳይ 25% ሰጠመ። ይህ ፍጹም ትክክል ነው ፣ ምክንያቱም ስለ ድጋሚ ማስተላለፍ ምንም አያውቅም ፣ እሽጎችን ይልካል እና በቀላሉ የተቀበሉት እና የጠፉ እሽጎች ብዛት ይቆጥራል።

እና በቀኝ በኩል የአገልግሎቶች መርሃ ግብር ነው. የችግር መገጣጠሚያ ውጤት እዚህ አያገኙም። በዚያው ሚሊሰከንዶች ውስጥ ያለው ትራፊክ ችግሩ ከተፈጠረበት አካባቢ ወደ ቀሩት ሶስት ማገናኛዎች በችግሩ ያልተነካ ፈሰሰ። ራሱን የሚፈውስ ኔትወርክ አግኝተናል።

ይህ የመጨረሻው ስላይድ ነው፣ ለመገመት ጊዜው ነው። አሁን፣ እራስን የሚፈውስ የመረጃ ማዕከል አውታረመረብ እንዴት እንደሚገነቡ እንደሚያውቁ ተስፋ አደርጋለሁ። በሊኑክስ ከርነል መዝገብ ውስጥ ማለፍ እና እዚያ ልዩ ጥገናዎችን መፈለግ አያስፈልግዎትም ፣ የፍሰት መለያው በዚህ ጉዳይ ላይ ችግሩን እንደሚፈታ ያውቃሉ ፣ ግን ይህንን ዘዴ በጥንቃቄ መቅረብ ያስፈልግዎታል። እና ድምጸ ተያያዥ ሞደም ከሆንክ የፍሰት መለያውን እንደ ሃሽ ተግባር መጠቀም እንደሌለብህ በድጋሚ አፅንዖት እሰጣለሁ፣ ያለበለዚያ የተጠቃሚህን ክፍለ ጊዜ ትሰብራለህ።

ለኔትወርክ መሐንዲሶች የፅንሰ-ሀሳብ ለውጥ መደረግ አለበት፡ አውታረ መረቡ የሚጀምረው በቶር ሳይሆን በኔትወርክ መሳሪያ ሳይሆን በአስተናጋጅ ነው። በጣም የሚያስደንቀው ምሳሌ RTO ን ለመለወጥ እና ወደ ማንኛውም የቀረጻ አገልግሎቶች የፍሰት መለያ ለማስተካከል eBPF ሁለቱንም እንዴት እንደምንጠቀም ነው።

የፍሰት መለያው መካኒክ በእርግጠኝነት ቁጥጥር ባለው የአስተዳደር ክፍል ውስጥ ላሉ ሌሎች አገልግሎቶች ተስማሚ ነው። ይህ በመረጃ ማእከሎች መካከል ያለው ትራፊክ ሊሆን ይችላል ወይም የወጪ ትራፊክን ለመቆጣጠር እንደዚህ ያሉ መካኒኮችን በልዩ መንገድ መጠቀም ይችላሉ። ግን ስለዚህ ጉዳይ እናገራለሁ, ተስፋ አደርጋለሁ, በሚቀጥለው ጊዜ. ስለ ትኩረትዎ በጣም እናመሰግናለን።

ምንጭ: hab.com