በ Yandex.Cloud ውስጥ የአውታረ መረብ ጭነት ሚዛን አርክቴክቸር

ጤና ይስጥልኝ እኔ ሰርጌይ Elantsev ነኝ ፣ እገነባለሁ። የአውታረ መረብ ጭነት ሚዛን በ Yandex.Cloud. ከዚህ ቀደም የኤል 7 ሚዛኑን ለ Yandex ፖርታል ልማት መርቻለሁ - ባልደረቦች ምንም ብሰራ ሚዛኑን የጠበቀ እንደሆነ ይቀልዳሉ። ለሃብር አንባቢዎች ጭነቱን በደመና መድረክ ውስጥ እንዴት ማስተዳደር እንደሚቻል፣ ይህንን ግብ ለማሳካት እንደ ምርጥ መሳሪያ የምንመለከተውን እና ይህንን መሳሪያ ወደ ግንባታ እንዴት እንደምንሄድ እነግራቸዋለሁ።

በመጀመሪያ፣ አንዳንድ ቃላትን እናስተዋውቅ፡-

• ቪአይፒ (ምናባዊ አይፒ) - ሚዛናዊ አይፒ አድራሻ
• አገልጋይ ፣ ጀርባ ፣ ለምሳሌ - መተግበሪያን የሚያሄድ ምናባዊ ማሽን
• RIP (እውነተኛ አይፒ) - የአገልጋይ IP አድራሻ
• Healthcheck - የአገልጋይ ዝግጁነት ማረጋገጥ
• ተገኝነት ዞን, AZ - በመረጃ ማዕከል ውስጥ ገለልተኛ መሠረተ ልማት
• ክልል - የተለያዩ AZs ህብረት

የጭነት ማመሳከሪያዎች ሶስት ዋና ዋና ተግባራትን ይፈታሉ-ሚዛኑን በራሱ ያከናውናሉ, የአገልግሎቱን ስህተት መቻቻል ያሻሽላሉ እና መጠኑን ያቃልላሉ. የስህተት መቻቻል በአውቶማቲክ የትራፊክ አስተዳደር ይረጋገጣል፡- ሚዛኑ የመተግበሪያውን ሁኔታ ይከታተላል እና የህይወት ቼክን የማያልፉ ሁኔታዎችን ከማመጣጠን አያካትትም። ሸክሙን በእኩል መጠን በማሰራጨት እና እንዲሁም በበረራ ላይ ያሉ የአብነት ዝርዝሮችን በማዘመን ልኬቱ ይረጋገጣል። ሚዛኑ በቂ ካልሆነ፣ አንዳንድ አጋጣሚዎች ከአቅም ገደብ በላይ የሆነ ሸክም ይቀበላሉ፣ እና አገልግሎቱ አስተማማኝ አይሆንም።

የጭነት ሚዛን ብዙውን ጊዜ ከሚሠራው የ OSI ሞዴል በፕሮቶኮል ንብርብር ይመደባል። የ Cloud Balancer የሚሰራው በ TCP ደረጃ ሲሆን ይህም ከአራተኛው ንብርብር L4 ጋር ይዛመዳል።

ወደ የክላውድ ሚዛን አርክቴክቸር አጠቃላይ እይታ እንሂድ። ቀስ በቀስ የዝርዝሩን ደረጃ እንጨምራለን. የተመጣጠነ ክፍሎችን በሶስት ክፍሎች እንከፍላለን. የማዋቀር አውሮፕላን ክፍል ለተጠቃሚ መስተጋብር ኃላፊነት አለበት እና የስርዓቱን ኢላማ ሁኔታ ያከማቻል። የመቆጣጠሪያው አውሮፕላኑ የስርዓቱን ወቅታዊ ሁኔታ ያከማቻል እና ከዳታ አውሮፕላን ክፍል ያሉትን ስርዓቶች ያስተዳድራል፣ ይህም ከደንበኞች ወደ እርስዎ አጋጣሚዎች ትራፊክ የማድረስ ቀጥተኛ ኃላፊነት ነው።

የውሂብ አውሮፕላን

ትራፊኩ የሚያበቃው ድንበር ራውተር በሚባሉ ውድ መሳሪያዎች ነው። የስህተት መቻቻልን ለመጨመር ብዙ እንደዚህ ያሉ መሳሪያዎች በአንድ የውሂብ ማዕከል ውስጥ በአንድ ጊዜ ይሰራሉ። በመቀጠል፣ ትራፊኩ ወደ ሚዛኖች ይሄዳል፣ የትኛውንም የተለቀቀ የአይፒ አድራሻ ለሁሉም AZ በBGP ለደንበኞች ያስታውቃል። 

ትራፊክ በ ECMP ላይ ይተላለፋል - ይህ ወደ ዒላማው ብዙ እኩል ጥሩ መንገዶች ሊኖሩበት የሚችልበት የማዞሪያ ስልት ነው (በእኛ ሁኔታ ኢላማው መድረሻው IP አድራሻ ይሆናል) እና ፓኬቶች በማንኛቸውም ሊላኩ ይችላሉ። በተጨማሪም በሚከተለው እቅድ መሰረት በበርካታ የተደራሽ ዞኖች ውስጥ ስራን እንደግፋለን፡ በእያንዳንዱ ዞን አድራሻ እናስተዋውቃለን, ትራፊክ ወደ ቅርብ ወደሆነው ይሄዳል እና ከገደቡ በላይ አይሄድም. በኋላ ላይ በትራፊክ ላይ ምን እንደሚፈጠር በበለጠ ዝርዝር እንመለከታለን.

አውሮፕላን አዋቅር

 
የማዋቀር አውሮፕላኑ ቁልፍ አካል ኤፒአይ ነው፣ በዚህም መሰረታዊ ክንዋኔዎች ከሚዛን ሰጪዎች ጋር ይከናወናሉ፡ መፍጠር፣ መሰረዝ፣ የአጋጣሚዎችን ስብጥር መቀየር፣ የጤና ምርመራ ውጤቶችን ማግኘት፣ ወዘተ. በአንድ በኩል ይህ REST API ነው፣ እና በ ሌላ፣ እኛ ክላውድ ውስጥ ያለን ብዙ ጊዜ gRPCን ፍሬም እንጠቀማለን፣ ስለዚህ REST ወደ gRPC “እናተረጉማለን” እና ከዚያ gRPCን ብቻ እንጠቀማለን። ማንኛውም ጥያቄ በአንድ የጋራ የ Yandex.Cloud ሠራተኞች ገንዳ ላይ የሚፈጸሙ ተከታታይ ያልተመሳሰሉ ኃይላቸው ተግባራትን ወደመፍጠር ይመራል። ተግባራት በማንኛውም ጊዜ ሊታገዱ እና እንደገና እንዲጀምሩ በሚያስችል መንገድ ተጽፈዋል። ይህ መጠነ-ሰፊነት, ተደጋጋሚነት እና ስራዎችን መመዝገብን ያረጋግጣል.

በውጤቱም, ከኤፒአይ ውስጥ ያለው ተግባር በ Go ውስጥ የተፃፈውን የሂሳብ መቆጣጠሪያ አገልግሎት ተቆጣጣሪ ጥያቄ ያቀርባል. ሚዛን ሰጪዎችን ማከል እና ማስወገድ ፣የጀርባዎችን እና ቅንብሮችን ስብጥር መለወጥ ይችላል። 

አገልግሎቱ በ Yandex ዳታቤዝ ውስጥ ያለውን ሁኔታ ያከማቻል፣ በተከፋፈለ የሚተዳደር የውሂብ ጎታ በቅርቡ መጠቀም ይችላሉ። በ Yandex.Cloud ውስጥ, ልክ እንደ እኛ አስቀድመን የተነገረውየውሻ ምግብ ጽንሰ-ሀሳብ ተግባራዊ ይሆናል፡ እኛ እራሳችን አገልግሎቶቻችንን ከተጠቀምን ደንበኞቻችንም በደስታ ይጠቀማሉ። የ Yandex ዳታቤዝ የእንደዚህ አይነት ጽንሰ-ሀሳብ አተገባበር ምሳሌ ነው. ሁሉንም ውሂቦቻችንን በ YDB ውስጥ እናከማቻለን, እና የውሂብ ጎታውን ስለመጠበቅ እና ስለማመጣጠን ማሰብ የለብንም: እነዚህ ችግሮች ለእኛ ተፈትተዋል, የውሂብ ጎታውን እንደ አገልግሎት እንጠቀማለን.

ወደ ሚዛኑ መቆጣጠሪያ እንመለስ። ተግባሩ ስለ ሚዛኑ መረጃ መቆጠብ እና የቨርቹዋል ማሽኑን ዝግጁነት ወደ ጤና ቼክ ተቆጣጣሪው ለመፈተሽ ተግባር መላክ ነው።

የጤና ምርመራ መቆጣጠሪያ

የቼክ ደንቦችን የመቀየር ጥያቄዎችን ይቀበላል ፣ በ YDB ውስጥ ያስቀምጣቸዋል ፣ ተግባሮችን በ healtcheck ኖዶች መካከል ያሰራጫል እና ውጤቶቹን ያጠቃለለ ፣ ከዚያም ወደ ዳታቤዝ ይቀመጡ እና ወደ ሎድባላንደር መቆጣጠሪያ ይላካሉ። እሱ, በተራው, በመረጃ አውሮፕላን ውስጥ ያለውን የክላስተር ስብጥር ወደ ሎድባላስተር-ኖድ ለመቀየር ጥያቄ ይልካል, እኔ ከዚህ በታች እንነጋገራለን.

ስለ ጤና ምርመራዎች የበለጠ እንነጋገር። እነሱ በበርካታ ክፍሎች ሊከፋፈሉ ይችላሉ. ኦዲቶች የተለያዩ የስኬት መስፈርቶች አሏቸው። TCP ቼኮች በተወሰነ ጊዜ ውስጥ ግንኙነትን በተሳካ ሁኔታ መመስረት አለባቸው። የኤችቲቲፒ ቼኮች ሁለቱንም የተሳካ ግንኙነት እና የ200 ሁኔታ ኮድ ያለው ምላሽ ያስፈልጋቸዋል።

እንዲሁም, ቼኮች በድርጊት ክፍል ውስጥ ይለያያሉ - ንቁ እና ንቁ ናቸው. ተገብሮ ቼኮች ምንም አይነት ልዩ እርምጃ ሳይወስዱ በትራፊክ ምን እንደሚከሰት በቀላሉ ይቆጣጠራሉ። ይህ በ L4 ላይ በጣም ጥሩ አይሰራም ምክንያቱም በከፍተኛ ደረጃ ፕሮቶኮሎች አመክንዮ ላይ የተመሰረተ ነው፡ L4 ላይ ቀዶ ጥገናው ለምን ያህል ጊዜ እንደወሰደ ወይም ግንኙነቱ መጠናቀቁ ጥሩ ወይም መጥፎ ስለመሆኑ ምንም መረጃ የለም። ገባሪ ቼኮች ለእያንዳንዱ የአገልጋይ ምሳሌ ጥያቄዎችን እንዲልክ ሚዛኑ ያስፈልጋቸዋል።

አብዛኛዎቹ የጭነት ማመሳከሪያዎች ራሳቸው የህይወት ፍተሻዎችን ያከናውናሉ. ክላውድ ላይ፣ መስፋፋትን ለመጨመር እነዚህን የስርዓቱን ክፍሎች ለመለየት ወስነናል። ይህ አካሄድ ለአገልግሎቱ የጤና ምርመራ ጥያቄዎችን እየጠበቅን የሒሳብ ሰጪዎችን ቁጥር ለመጨመር ያስችለናል። ቼኮች የሚከናወኑት በተለየ የጤንነት ማረጋገጫ ኖዶች ነው፣ በዚህ ላይ የፍተሻ ኢላማዎች የተበጣጠሱ እና የተባዙ ናቸው። ሊሳካ ስለሚችል ከአንድ አስተናጋጅ ቼኮችን ማከናወን አይችሉም። ያኔ እሱ የመረመረባቸውን ሁኔታዎች ሁኔታ አናገኝም። ማናቸውንም አጋጣሚዎች ቢያንስ ከሶስት የጤና አጠባበቅ ኖዶች ቼኮች እናደርጋለን። ወጥ የሆነ የሃሽ ስልተ ቀመሮችን በመጠቀም የፍተሻዎች አላማዎችን በመስቀለኛ ቋቶች መካከል እንከፋፍላለን።

ማመጣጠን እና የጤና ምርመራን መለየት ወደ ችግሮች ሊመራ ይችላል. የጤና ቼክ መስቀለኛ መንገድ ለአብነት ጥያቄ ካቀረበ፣ ሚዛኑን በማቋረጥ (በአሁኑ ጊዜ ትራፊክን የማያገለግል)፣ ከዚያ እንግዳ የሆነ ሁኔታ ይፈጠራል፡ ሀብቱ በህይወት ያለ ይመስላል፣ ነገር ግን ትራፊኩ አይደርስበትም። ይህንን ችግር በዚህ መንገድ እንፈታዋለን፡ የጤንነት ፍተሻ ትራፊክን በተመጣጣኝ ተቆጣጣሪዎች ለመጀመር ዋስትና ተሰጥቶናል። በሌላ አገላለጽ ፣ ከደንበኞች እና ከጤና ቼኮች ጋር ፓኬጆችን ለማንቀሳቀስ እቅድ በትንሹ ይለያያል-በሁለቱም ፣ እሽጎች ወደ ሚዛኖቹ ይደርሳሉ ፣ ይህም ወደ ዒላማ ሀብቶች ያደርሳቸዋል።

ልዩነቱ ደንበኞች ለቪአይፒ ጥያቄ ሲያቀርቡ የጤና ቼኮች ደግሞ ለእያንዳንዱ ግለሰብ RIP ይጠይቃሉ። እዚህ ላይ አንድ አስደሳች ችግር ይፈጠራል-ተጠቃሚዎቻችን በግራጫ IP አውታረ መረቦች ውስጥ ሀብቶችን እንዲፈጥሩ እድል እንሰጣለን. ሁለት የተለያዩ የደመና ባለቤቶች አገልግሎታቸውን ከሚዛን ሰጪዎች ጀርባ የደበቁ እንዳሉ እናስብ። እያንዳንዳቸው በ 10.0.0.1/24 ንኡስ መረብ ውስጥ ተመሳሳይ አድራሻዎች ያላቸው ሀብቶች አሏቸው. በሆነ መንገድ እነሱን መለየት መቻል አለብዎት, እና እዚህ ወደ Yandex.Cloud ምናባዊ አውታረ መረብ መዋቅር ውስጥ ዘልለው መግባት አለብዎት. ተጨማሪ ዝርዝሮችን ማግኘት የተሻለ ነው ቪዲዮ ስለ: ደመና ክስተት, አሁን ለእኛ አስፈላጊ ነው አውታረ መረቡ ብዙ ሽፋን ያለው እና በንዑስኔት መታወቂያ ሊለዩ የሚችሉ ዋሻዎች አሉት.

ኳሲ-IPv6 የሚባሉትን አድራሻዎች በመጠቀም የሄልዝኬክ ኖዶችን ያነጋግሩ። Quasi-address በውስጡ የ IPv6 አድራሻ እና የተጠቃሚ ንዑስ መረብ መታወቂያ ያለው የIPv4 አድራሻ ነው። ትራፊኩ ወደ ሚዛኑ ይደርሳል፣ የ IPv4 መገልገያ አድራሻውን ከእሱ ያወጣል፣ IPv6 ን በ IPv4 ይተካ እና ፓኬጁን ወደ ተጠቃሚው አውታረመረብ ይልካል።

የተገላቢጦሹ ትራፊክ በተመሳሳይ መንገድ ይሄዳል፡- ሚዛኑ ሚዛኑ መድረሻው ከጤና ተቆጣጣሪዎች ግራጫ ኔትወርክ መሆኑን ያያል እና IPv4 ን ወደ IPv6 ይቀይራል።

VPP - የውሂብ አውሮፕላን ልብ

ሚዛኑ የሚተገበረው የቬክተር ፓኬት ፕሮሰሲንግ (VPP) ቴክኖሎጂን በመጠቀም ሲሆን ከሲስኮ የአውታረ መረብ ትራፊክ ባች ሂደት ነው። በእኛ ሁኔታ, ማዕቀፉ በተጠቃሚ-ቦታ አውታረ መረብ መሳሪያ አስተዳደር ቤተ-መጽሐፍት ላይ - የውሂብ ፕላኔ ልማት ኪት (DPDK) ላይ ይሰራል. ይህ ከፍተኛ የፓኬት ሂደት አፈጻጸምን ያረጋግጣል፡ በከርነል ውስጥ በጣም ያነሱ መቆራረጦች ይከሰታሉ፣ እና በከርነል ቦታ እና በተጠቃሚ ቦታ መካከል ምንም አይነት የአውድ መቀየሪያዎች የሉም። 

VPP ከዚህም በላይ ይሄዳል እና ፓኬጆችን ወደ ባች በማጣመር ከሲስተሙ የበለጠ አፈጻጸምን ያስወጣል። አፈጻጸሙ የተገኘው በዘመናዊ ፕሮሰሰሮች ላይ መሸጎጫዎችን በኃይል በመጠቀም ነው። ሁለቱም የመረጃ መሸጎጫዎች ጥቅም ላይ ይውላሉ (እሽጎች በ "ቬክተሮች" ውስጥ ይከናወናሉ, ውሂቡ እርስ በርስ ይቀራረባል) እና የመመሪያ መሸጎጫዎች: በ VPP ውስጥ, የፓኬት ማቀናበሪያ ግራፍ ይከተላል, አንጓዎቹ ተመሳሳይ ተግባር የሚያከናውኑ ተግባራትን ይይዛሉ.

ለምሳሌ, በ VPP ውስጥ የአይፒ ፓኬቶችን ማቀነባበር የሚከናወነው በሚከተለው ቅደም ተከተል ነው: በመጀመሪያ, የፓኬቱ ራስጌዎች በመተንተን መስቀለኛ መንገድ ውስጥ ይለጠፋሉ, ከዚያም ወደ መስቀለኛ መንገድ ይላካሉ, ይህም ፓኬቶችን በማዞሪያ ሰንጠረዦች መሰረት የበለጠ ያስተላልፋል.

ትንሽ ሃርድኮር። የቪፒፒ ደራሲዎች በአቀነባባሪ መሸጎጫዎች አጠቃቀም ላይ ድርድርን አይታገሡም ፣ ስለሆነም የፓኬቶችን ቬክተር ለማስኬድ የተለመደው ኮድ በእጅ ቬክተር ማድረግን ይይዛል-“በወረፋው ውስጥ አራት እሽጎች አሉን” ያለ ሁኔታ የሚሠራበት የማቀነባበሪያ ዑደት አለ ። ከዚያም ለሁለት ተመሳሳይ, ከዚያም - ለአንድ. Prefetch መመሪያዎች ብዙ ጊዜ ውሂብን ወደ መሸጎጫዎች ለመጫን ጥቅም ላይ የሚውሉት በሚቀጥሉት ድግግሞሾች ውስጥ መዳረሻን ለማፋጠን ነው።

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

ስለዚህ፣ Healthchecks በIPv6 ወደ VPP ያወራሉ፣ ይህም ወደ IPv4 ይቀይራቸዋል። ይህ የሚከናወነው በግራፉ ውስጥ ባለው መስቀለኛ መንገድ ነው, እሱም አልጎሪዝም NAT ብለን እንጠራዋለን. ለተገላቢጦሽ ትራፊክ (እና ከ IPv6 ወደ IPv4 መቀየር) ተመሳሳይ አልጎሪዝም NAT መስቀለኛ መንገድ አለ.

ከተመጣጣኝ ደንበኞች ቀጥተኛ ትራፊክ በግራፍ ኖዶች ውስጥ ያልፋል, ይህም ሚዛኑን በራሱ ያከናውናል. 

የመጀመሪያው አንጓ የሚጣበቁ ክፍለ ጊዜዎች ነው. የ hash ያከማቻል 5-tuple ለተቋቋሙ ክፍለ ጊዜዎች. 5-tuple መረጃ የሚተላለፍበት የደንበኛው አድራሻ እና ወደብ ፣ ትራፊክ ለመቀበል የሚገኙትን ሀብቶች አድራሻ እና ወደቦች እንዲሁም የአውታረ መረብ ፕሮቶኮልን ያጠቃልላል። 

ባለ 5-tuple hash በቀጣይ ተከታታይ ሃሽ ኖድ ውስጥ አነስተኛ ስሌት እንድናከናውን ይረዳናል፣እንዲሁም ከተመጣጣኝ ጀርባ የተሻለ እጀታ ያለው የመረጃ ዝርዝር ለውጦች። ምንም ክፍለ ጊዜ የሌለበት ፓኬት ወደ ሚዛኑ ሲደርስ ወደ ወጥነት ያለው የሃሺንግ መስቀለኛ መንገድ ይላካል። ወጥነት ያለው ሀሺን በመጠቀም ማመጣጠን የሚከሰትበት ቦታ ነው፡ ካሉት “የቀጥታ” ሀብቶች ዝርዝር ውስጥ መርጃ እንመርጣለን። በመቀጠል, ፓኬጆቹ ወደ NAT መስቀለኛ መንገድ ይላካሉ, ይህም የመድረሻ አድራሻውን በትክክል ይተካዋል እና ቼኮችን እንደገና ያሰላል. እንደሚመለከቱት ፣ የ VPP ህጎችን እንከተላለን - ልክ እንደ መውደድ ፣ ተመሳሳይ ስሌቶችን በማቧደን የማቀነባበሪያ መሸጎጫዎችን ውጤታማነት ለማሳደግ።

ወጥነት ያለው ሃሽንግ

ለምንድነው የመረጥነው እና ምንድነው? በመጀመሪያ, የቀደመውን ተግባር እናስብ - ከዝርዝሩ ውስጥ አንድ መርጃ መምረጥ. 

ወጥነት በሌለው ሃሺንግ፣ የመጪው ፓኬት ሃሽ ይሰላል፣ እና አንድ ግብዓት ከዝርዝሩ ውስጥ በቀሪው ይህንን ሃሽ በንብረቶች ብዛት በማካፈል ይመረጣል። ዝርዝሩ እስካልተቀየረ ድረስ, ይህ እቅድ በጥሩ ሁኔታ ይሰራል: ሁልጊዜ ተመሳሳይ 5-tuple ያላቸው ፓኬቶችን ወደ ተመሳሳይ ምሳሌ እንልካለን. ለምሳሌ አንዳንድ ምንጮች ለጤና ምርመራዎች ምላሽ መስጠት ካቆሙ፣ ለትልቅ የሃሽዎቹ ክፍል ምርጫው ይለወጣል። የደንበኛው የTCP ግንኙነቶች ይቋረጣሉ፡ ቀደም ሲል ለምሳሌ A ላይ የደረሰው ፓኬት ወደ ለምሳሌ B መድረስ ሊጀምር ይችላል፣ ይህም የዚህን ጥቅል ክፍለ ጊዜ የማያውቀው።

ወጥነት ያለው ሃሽንግ የተገለጸውን ችግር ይፈታል. ይህንን ጽንሰ-ሀሳብ ለማብራራት ቀላሉ መንገድ ይህ ነው፡ ሃብቶችን በሃሽ የምታከፋፍሉበት ቀለበት እንዳለህ አስብ (ለምሳሌ በአይፒ፡ ወደብ)። ሀብትን መምረጥ መንኮራኩሩን ወደ አንግል ማዞር ሲሆን ይህም በፓኬቱ ሃሽ የሚወሰን ነው።

ይህ የሀብት ስብጥር ሲቀየር የትራፊክ መልሶ ማከፋፈልን ይቀንሳል። ሀብትን መሰረዝ ሀብቱ የሚገኝበትን ወጥ የሆነ የሃሽንግ ቀለበት ክፍል ብቻ ነው የሚነካው። ምንጭ ማከል ስርጭቱንም ይለውጠዋል፣ ነገር ግን ተለጣፊ የክፍለ-ጊዜዎች መስቀለኛ መንገድ አለን፣ ይህም ቀደም ሲል የተቋቋሙ ክፍለ-ጊዜዎችን ወደ አዲስ ሀብቶች እንዳንቀይር ያስችለናል።

በተመጣጣኝ እና በንብረቶች መካከል ያለውን ትራፊክ ለመምራት ምን እንደሚከሰት ተመልክተናል. አሁን የመመለሻ ትራፊክን እንመልከት። ልክ እንደ ፍተሻ ትራፊክ ተመሳሳይ ስርዓተ-ጥለት ይከተላል - በአልጎሪዝም NAT፣ ማለትም በግልባጭ NAT 44 ለደንበኛ ትራፊክ እና በ NAT 46 ለጤና ቁጥጥር ትራፊክ። የራሳችንን እቅድ እናከብራለን፡ የጤና ቼኮች ትራፊክ እና እውነተኛ የተጠቃሚ ትራፊክን አንድ እናደርጋለን።

Loadbalancer-node እና የተገጣጠሙ ክፍሎች

በ VPP ውስጥ ያሉ ሚዛን ሰጪዎች እና ሀብቶች ስብጥር በአካባቢው አገልግሎት - ሎድባላስተር-ኖድ ሪፖርት ተደርጓል. ከሎድባላስተር-ተቆጣጣሪው የክስተቶች ዥረት ይመዘገባል እና አሁን ባለው የቪፒፒ ሁኔታ እና ከተቆጣጣሪው በተቀበለው ዒላማ ሁኔታ መካከል ያለውን ልዩነት ማቀድ ይችላል። የተዘጋ ስርዓት እናገኛለን፡ ከኤፒአይ የሚመጡ ክስተቶች ወደ ሚዛኑ መቆጣጠሪያ ይመጣሉ፣ ይህም የሃብቶችን “ህያውነት” ለማረጋገጥ ለጤና ቼክ ተቆጣጣሪው ተግባራትን ይመድባል። ያ ፣ በተራው ፣ ተግባሮችን ለጤና ቼክ-ኖድ ይመድባል እና ውጤቶቹን ያጠቃለለ ፣ ከዚያ በኋላ ወደ ሚዛኑ መቆጣጠሪያ ይልካቸዋል። Loadbalancer-node ከመቆጣጠሪያው የሚመጡ ክስተቶችን ይመዘግባል እና የ VPP ሁኔታን ይለውጣል። በእንደዚህ ዓይነት ስርዓት ውስጥ እያንዳንዱ አገልግሎት ስለ ጎረቤት አገልግሎቶች አስፈላጊ የሆነውን ብቻ ያውቃል. የግንኙነቶች ብዛት ውስን ነው እና የተለያዩ ክፍሎችን በተናጥል የመስራት እና የመጠን ችሎታ አለን።

ምን ጉዳዮች ተወግደዋል?

በመቆጣጠሪያ አውሮፕላን ውስጥ ያሉት ሁሉም አገልግሎቶቻችን በ Go ውስጥ የተፃፉ እና ጥሩ የመጠን እና አስተማማኝነት ባህሪያት አሏቸው. Go የተከፋፈሉ ስርዓቶችን ለመገንባት ብዙ ክፍት ምንጭ ቤተ-ፍርግሞች አሉት። GRPCን በንቃት እንጠቀማለን ፣ ሁሉም አካላት የአገልግሎት ግኝት ክፍት ምንጭ ትግበራን ይይዛሉ - አገልግሎታችን የእያንዳንዳችንን አፈፃፀም ይቆጣጠራል ፣ ስብስባቸውን በተለዋዋጭ ሊለውጥ ይችላል እና ይህንን ከ GRPC ማመጣጠን ጋር አገናኘነው። ለሜትሪዎች፣ ክፍት ምንጭ መፍትሄንም እንጠቀማለን። በመረጃ አውሮፕላኑ ውስጥ ጥሩ አፈፃፀም እና ትልቅ የመርጃ ክምችት አግኝተናል-ከብረት ኔትወርክ ካርድ ይልቅ በቪፒፒ አፈፃፀም ላይ የምንተማመንበትን መቆሚያ ለመሰብሰብ በጣም አስቸጋሪ ሆነ ።

ችግሮች እና መፍትሄዎች

በደንብ ያልሰራው ምንድን ነው? Go አውቶማቲክ የማህደረ ትውስታ አስተዳደር አለው፣ ነገር ግን የማህደረ ትውስታ ፍንጣቂዎች አሁንም ይከሰታሉ። እነሱን ለመቋቋም ቀላሉ መንገድ ጎሮቲንን ማስኬድ እና እነሱን ማቋረጡን ማስታወስ ነው። መውሰድ፡ የ Go ፕሮግራሞችን የማስታወሻ ፍጆታ ይመልከቱ። ብዙውን ጊዜ ጥሩ አመላካች የ goroutines ብዛት ነው. በዚህ ታሪክ ውስጥ ተጨማሪ ነገር አለ፡ በGo ውስጥ የሩጫ ጊዜ ውሂብን ማግኘት ቀላል ነው - የማህደረ ትውስታ ፍጆታ፣ የሩጫ ጎሮቲኖች ብዛት እና ሌሎች ብዙ መመዘኛዎች።

እንዲሁም ሂድ ለተግባራዊ ሙከራዎች ምርጥ ምርጫ ላይሆን ይችላል። እነሱ በጣም በቃላት ናቸው, እና "ሁሉንም ነገር በ CI ውስጥ በቡድን ማሄድ" የሚለው መደበኛ አቀራረብ ለእነሱ በጣም ተስማሚ አይደለም. እውነታው ግን የተግባር ሙከራዎች የበለጠ ሀብትን የሚጠይቁ እና ትክክለኛ የጊዜ ማብቂያዎችን ያስከትላሉ። በዚህ ምክንያት ሲፒዩ በአሃድ ሙከራዎች የተጠመደ ስለሆነ ሙከራዎች ሊሳኩ ይችላሉ። ማጠቃለያ: ከተቻለ "ከባድ" ሙከራዎችን ከአሃድ ሙከራዎች ለይተው ያካሂዱ. 

የማይክሮ አገልግሎት ክስተት አርክቴክቸር ከአንድ ሞኖሊት የበለጠ ውስብስብ ነው፡ በደርዘን በሚቆጠሩ የተለያዩ ማሽኖች ላይ መዝገቦችን መሰብሰብ በጣም ምቹ አይደለም። ማጠቃለያ: ማይክሮ ሰርቪስ ካደረጉ ወዲያውኑ ስለ ፍለጋ ያስቡ.

የእኛ እቅዶች

የውስጥ ሚዛን (IPv6) ሚዛን አስጀምረናል፣ ለ Kubernetes ስክሪፕቶች ድጋፍ እንጨምራለን፣ አገልግሎቶቻችንን መቆራረጡን እንቀጥላለን (በአሁኑ ጊዜ የጤና አጠባበቅ-ኖድ እና የጤንነት ማረጋገጫ-ctrl ብቻ የተቆራረጡ ናቸው)፣ አዲስ የጤና ምርመራዎችን እንጨምራለን እና እንዲሁም የቼኮች ብልጥ ማጠቃለያን ተግባራዊ እናደርጋለን። አገልግሎቶቻችንን የበለጠ ገለልተኛ የማድረግ እድል እያጤንን ነው - ስለዚህ እርስ በእርስ በቀጥታ እንዳይገናኙ ፣ ግን የመልእክት ወረፋ በመጠቀም። ከSQS ጋር ተኳሃኝ የሆነ አገልግሎት በቅርቡ በደመና ውስጥ ታይቷል። የ Yandex መልእክት ወረፋ.

በቅርቡ የ Yandex Load Balancer ይፋዊ ልቀት ተካሂዷል። ያስሱ ሰነዶች ለአገልግሎቱ ፣ ሚዛን ሰጪዎችን ለእርስዎ በሚመች መንገድ ያስተዳድሩ እና የፕሮጀክቶችዎን ጥፋት መቻቻል ይጨምሩ!

ምንጭ: hab.com