ווי Badoo אַטשיווד די פיייקייט צו מאַכן 200 ק פאָטאָס פּער סעקונדע

די מאָדערן וועב איז כּמעט אַנטינגקאַבאַל אָן מעדיע אינהאַלט: כּמעט יעדער באָבע האט אַ סמאַרטפאָנע, אַלעמען איז אויף געזעלשאַפטלעך נעטוואָרקס, און דאַונטיים אין וישאַלט איז טייַער פֿאַר קאָמפּאַניעס. דאָ איז אַ טראַנסקריפּט פון די פירמע 'ס געשיכטע באַדאָאָ וועגן ווי זי אָרגאַניזירט די עקספּרעס פון פאָטאָס ניצן אַ ייַזנוואַרג לייזונג, וואָס פאָרשטעלונג פּראָבלעמס זי געפּלאָנטערט אין דעם פּראָצעס, וואָס געפֿירט זיי, און ווי די פּראָבלעמס זענען סאַלווד ניצן אַ ווייכווארג לייזונג באזירט אויף Nginx, בשעת ינשורינג שולד טאָלעראַנץ אין אַלע לעוועלס (ווידעא). מיר דאַנקען די מחברים פון אָלעג ס געשיכטע סאַניס Efimova און Alexandra Dymova, וואָס האָבן שערד זייער דערפאַרונג אויף דער קאָנפֿערענץ ופּטימע טאָג 4.

— לאָמיר אָנהייבן מיט אַ ביסל הקדמה וועגן ווי מיר קראָם און קאַש פאָטאָס. מיר האָבן אַ שיכטע ווו מיר קראָם זיי, און אַ שיכטע ווו מיר קאַש די פאָטאָס. אין דער זעלביקער צייט, אויב מיר ווילן צו דערגרייכן אַ הויך טריק קורס און רעדוצירן די מאַסע אויף סטאָרידזש, עס איז וויכטיק פֿאַר אונדז אַז יעדער פאָטאָ פון אַ יחיד באַניצער איז אויף איין קאַטשינג סערווער. אַנדערש, מיר וואָלט האָבן צו ינסטאַלירן ווי פילע מאל מער דיסקס ווי מיר האָבן מער סערווערס. אונדזער טריק קורס איז אַרום 99%, דאָס איז, מיר רעדוצירן די מאַסע אויף אונדזער סטאָרידזש מיט 100 מאל, און צו טאָן דאָס, 10 יאָר צוריק, ווען אַלע דעם איז געווען געבויט, מיר האָבן 50 סערווערס. אַקקאָרדינגלי, צו דינען די פאָטאָס, מיר דאַרפֿן בייסיקלי 50 פונדרויסנדיק דאָומיינז וואָס די סערווערס דינען.

געוויינטלעך, די קשיא איז גלייך אויפגעשטאנען: אויב איינער פון אונדזער סערווערס גייט אַראָפּ און ווערט אַנאַוויילאַבאַל, וואָס טייל פון די פאַרקער טאָן מיר פאַרלירן? מי ר האב ן זי ך געקוק ט װא ס אי ז געװע ן אויפ ן מארק , או ן באשלאס ן צ ו קויפ ן א שטיק ל אײרװארג , כד י ז י זאל ן לײז ן אל ע אונדזער ע פראבלעמען . די ברירה איז געפאלן אויף די לייזונג פון די F5-נעטוואָרק פירמע (וואָס, דורך דעם וועג, לעצטנס געקויפט NGINX, Inc): BIG-IP Local Traffic Manager.

וואָס דעם שטיק פון ייַזנוואַרג (LTM) טוט: עס איז אַן אייַזן ראַוטער וואָס מאכט אייַזן יבעריקייַט פון זייַן פונדרויסנדיק פּאָרץ און אַלאַוז איר צו מאַרשרוט פאַרקער באזירט אויף די נעץ טאַפּאַלאַדזשי, אויף עטלעכע סעטטינגס און טוט געזונט טשעקס. עס איז געווען וויכטיק צו אונדז אַז דעם שטיק פון ייַזנוואַרג קען זיין פּראָוגראַמד. אַקקאָרדינגלי, מיר קען באַשרייַבן די לאָגיק פון ווי פאָוטאַגראַפס פון אַ ספּעציפיש באַניצער זענען געדינט פֿון אַ ספּעציפיש קאַש. וויאַזוי קוקט עס אויס? עס איז אַ שטיק פון ייַזנוואַרג וואָס קוקט אויף די אינטערנעט אויף איין פעלד, איין IP, טוט ssl אָפלאָאַד, פּאַרסעס הטטפּ ריקוועס, סאַלעקץ אַ קאַש נומער פון IRule, ווו צו גיין, און לאָזן פאַרקער גיין דאָרט. אין דער זעלביקער צייט, עס טוט געזונט טשעקס, און אויב עטלעכע מאַשין איז אַנאַוויילאַבאַל, אין דער צייט מיר געמאכט עס אַזוי אַז די פאַרקער געגאנגען צו איין באַקאַפּ סערווער. פֿון אַ קאַנפיגיעריישאַן פונט פון מיינונג, עס זענען, פון קורס, עטלעכע נואַנסיז, אָבער אין אַלגעמיין אַלץ איז גאַנץ פּשוט: מיר פאַרשרייַבן אַ קאָרט, קאָרעספּאָנדענץ פון אַ זיכער נומער צו אונדזער IP אויף די נעץ, מיר זאָגן אַז מיר וועלן הערן אויף פּאָרץ 80 און 443, מיר זאָגן אַז אויב דער סערווער איז אַנאַוויילאַבאַל, איר דאַרפֿן צו שיקן פאַרקער צו די באַקאַפּ איינער, אין דעם פאַל די 35, און מיר באַשרייַבן אַ בינטל פון לאָגיק אויף ווי די אַרקאַטעקטשער זאָל זיין דיסאַסעמבאַלד. דער בלויז פּראָבלעם איז געווען אַז די שפּראַך אין וואָס די ייַזנוואַרג איז פּראָוגראַמד איז געווען Tcl. אויב ווער עס יז געדענקט דעם אין אַלע ... די שפּראַך איז מער שרייַבן-בלויז ווי אַ שפּראַך באַקוועם פֿאַר פּראָגראַממינג:

וואָס האָבן מיר באַקומען? מיר באקומען אַ שטיק פון ייַזנוואַרג וואָס ינשורז הויך אַוויילאַבילאַטי פון אונדזער ינפראַסטראַקטשער, רוץ אַלע אונדזער פאַרקער, גיט געזונט בענעפיץ און נאָר אַרבעט. דערצו, עס אַרבעט פֿאַר אַ לאַנג צייַט: אין די לעצטע 10 יאָר עס זענען קיין טענות וועגן אים. אין די אָנהייב פון 2018, מיר האָבן שוין געשיקט וועגן 80 ק פאָטאָס פּער סעקונדע. דאָס איז ערגעץ אַרום 80 גיגאבייט פון פאַרקער פֿון ביידע אונדזער דאַטן סענטערס.

אָבער…

אין די אָנהייב פון 2018, מיר געזען אַ מיעס בילד אויף די טשאַרץ: די צייט עס גענומען צו שיקן פאָטאָס איז קלאר געוואקסן. און עס האט אויפגעהערט צו פאסן אונדז. די פּראָבלעם איז אַז די נאַטור איז קענטיק בלויז אין די שפּיץ פון פאַרקער - פֿאַר אונדזער פירמע איז די נאַכט פון זונטיק צו מאנטאג. אבער די מנוחה פון די צייַט די סיסטעם ביכייווד ווי געוויינטלעך, קיין וואונדער פון דורכפאַל.

פונדעסטוועגן, די פּראָבלעם האט צו זיין סאַלווד. מי ר האב ן זי ך דערצײל ט מעגלעכ ע באטלענע , או ן מי ר האב ן ז ײ אנגעהויב ן אויסמעקן . ערשטער פון אַלע, פון קורס, מיר יקספּאַנדיד פונדרויסנדיק ופּלינקס, דורכגעקאָכט אַ גאַנץ קאָנטראָלירן פון ינערלעך ופּלינקס, און געפונען אַלע מעגלעך באַטאַלנעקס. אבער אַלע דעם האט נישט געבן אַ קלאָר ווי דער טאָג רעזולטאַט, די פּראָבלעם איז נישט פאַרשווונדן.

אן אנדער מעגלעך באַטאַלנעק איז געווען די פאָרשטעלונג פון די פאָטאָ קאַטשעס זיך. און מיר האָבן באַשלאָסן אַז טאָמער די פּראָבלעם רעסץ מיט זיי. נו, מיר יקספּאַנדיד די פאָרשטעלונג - דער הויפּט נעץ פּאָרץ אויף פאָטאָ קאַטשעס. אבער ווידער קיין קלאָר ווי דער טאָג פֿאַרבעסערונג איז געווען געזען. אין די סוף, מיר באַצאָלט נאָענט ופמערקזאַמקייַט צו די פאָרשטעלונג פון די LTM זיך, און דאָ מיר געזען אַ טרויעריק בילד אויף די גראַפס: די מאַסע אויף אַלע קפּוס סטאַרץ צו גיין סמודלי, אָבער פּלוצלינג קומט צו אַ פּלאַטאָ. אין דער זעלביקער צייט, LTM סטאַפּס ריספּאַנדינג אַדאַקוואַטלי צו געזונט טשעקס און ופּלינקס און הייבט צו ראַנדאַמלי ויסמעקן זיי, וואָס פירט צו ערנסט פאָרשטעלונג דערנידעריקונג.

אַז איז, מיר האָבן יידענאַפייד די מקור פון די פּראָבלעם, יידענאַפייד די באַטאַלנעק. עס בלייבט צו באַשליסן וואָס מיר וועלן טאָן.

דער ערשטער, מערסט קלאָר ווי דער טאָג זאַך וואָס מיר קען טאָן איז צו פאַרהייַנטיקן די LTM זיך. אבער עס זענען עטלעכע נואַנסיז דאָ, ווייַל די ייַזנוואַרג איז גאַנץ יינציק, איר וועט נישט גיין צו די ניראַסט סופּערמאַרק און קויפן עס. דאָס איז אַ באַזונדער קאָנטראַקט, אַ באַזונדער דערלויבעניש קאָנטראַקט, און עס וועט נעמען אַ פּלאַץ פון צייט. די צווייטע אָפּציע איז צו אָנהייבן טראכטן פֿאַר זיך, קומען אַרויף מיט דיין אייגענע לייזונג ניצן דיין אייגענע קאַמפּאָונאַנץ, פּרעפעראַבלי ניצן אַן אָפֿן אַקסעס פּראָגראַם. אַלע וואָס בלייבט איז צו באַשליסן וואָס פּונקט מיר וועלן קלייַבן פֿאַר דעם און ווי פיל צייט מיר וועלן פאַרברענגען אויף סאַלווינג דעם פּראָבלעם, ווייַל די יוזערז האָבן נישט באַקומען גענוג פאָטאָס. דעריבער, מיר דאַרפֿן צו טאָן דאָס אַלץ זייער, זייער געשווינד, קען מען זאָגן נעכטן.

זינט די אַרבעט געבלאזן ווי "טאָן עפּעס ווי געשווינד ווי מעגלעך און ניצן די ייַזנוואַרג וואָס מיר האָבן," דער ערשטער זאַך מיר געדאַנק איז געווען צו באַזייַטיקן עטלעכע נישט זייער שטאַרק מאשינען פון די פראָנט, שטעלן Nginx דאָרט, מיט וואָס מיר וויסן ווי צו. אַרבעט און פּרובירן צו ינסטרומענט אַלע די זעלבע לאָגיק אַז ייַזנוואַרג געוויינט צו טאָן. דאָס איז, אין פאַקט, מיר לינקס אונדזער ייַזנוואַרג, אינסטאַלירן נאָך 4 סערווערס וואָס מיר האָבן צו קאַנפיגיער, באשאפן פונדרויסנדיק דאָומיינז פֿאַר זיי, ענלעך צו ווי עס איז געווען 10 יאר צוריק ... מיר פאַרפאַלן אַ ביסל אין אַוויילאַבילאַטי אויב די מאשינען געפאלן, אָבער נאָך ווייניקער, זיי סאַלווד די פּראָבלעם פון אונדזער ניצערס לאָוקאַלי.

אַקקאָרדינגלי, די לאָגיק בלייבט די זעלבע: מיר ינסטאַלירן Nginx, עס קענען טאָן SSL-offload, מיר קענען עפעס פּראָגראַם די רוטינג לאָגיק, געזונט טשעקס אין די קאַנפיגיעריישאַנז און פשוט דופּליקאַט די לאָגיק וואָס מיר האָבן פריער.

לאמיר זיך אראפזעצן צו שרייבן קאנפיגס. אין ערשטער עס געווען אַז אַלץ איז געווען זייער פּשוט, אָבער, ליידער, עס איז זייער שווער צו געפֿינען מאַניואַלז פֿאַר יעדער אַרבעט. דעריבער, מיר טאָן נישט רעקאָמענדירן צו נאָר גאָגלינג "ווי צו קאַנפיגיער Nginx פֿאַר פאָטאָס": עס איז בעסער צו אָפּשיקן צו דער באַאַמטער דאַקיומענטיישאַן, וואָס וועט ווייַזן וואָס סעטטינגס זאָל זיין גערירט. אבער עס איז בעסער צו קלייַבן די ספּעציפיש פּאַראַמעטער זיך. נו, אַלץ איז פּשוט: מיר באַשרייַבן די סערווערס וואָס מיר האָבן, מיר באַשרייַבן די סערטיפיקאַץ ... אָבער די מערסט טשיקאַווע זאַך איז, אין פאַקט, די רוטינג לאָגיק זיך.

אין ערשטער עס געווען צו אונדז אַז מיר זענען פשוט דיסקרייבינג אונדזער אָרט, גלייַכן די נומער פון אונדזער פאָטאָ קאַש אין עס, ניצן אונדזער הענט אָדער אַ גענעראַטאָר צו באַשרייַבן ווי פילע אַפּסטרים מיר דאַרפֿן, אין יעדער אַפּסטרים מיר אָנווייַזן די סערווער צו וואָס די פאַרקער זאָל גיין, און אַ באַקאַפּ סערווער - אויב די הויפּט סערווער איז נישט בנימצא:

אָבער, מסתּמא, אויב אַלץ וואָלט געווען אַזוי פּשוט, וואָלטן מיר פּשוט אַהיים גיין און גאָרנישט געזאָגט. צום באַדויערן, מיט די פעליקייַט Nginx סעטטינגס, וואָס, אין אַלגעמיין, זענען געמאכט איבער פילע יאָרן פון אַנטוויקלונג און זענען נישט גאָר פּאַסיק פֿאַר דעם פאַל ... די קאַנפיגיער קוקט ווי דאָס: אויב עטלעכע אַפּסטרים סערווער האט אַ בעטן טעות אָדער טיימאַוט, Nginx שטענדיק סוויטשיז פאַרקער צו דער ווייַטער איינער. דערצו, נאָך דער ערשטער דורכפאַל, אין 10 סעקונדעס, די סערווער וועט זיין אויסגעדרייט אַוועק, ביידע דורך גרייַז און טיימאַוט - דאָס קען נישט זיין קאַנפיגיערד אין קיין וועג. אַז איז, אויב מיר באַזייַטיקן אָדער באַשטעטיק די טיימאַוט אָפּציע אין די אַפּסטרים דירעקטיוו, כאָטש Nginx וועט נישט פּראָצעס דעם בעטן און ריספּאַנד מיט עטלעכע נישט זייער גוט טעות, דער סערווער וועט פאַרמאַכן אַראָפּ.

צו ויסמיידן דעם, מיר האבן צוויי זאכן:

אַ) זיי פאַרבאָטן Nginx צו טאָן דאָס מאַניואַלי - און ליידער, דער בלויז וועג צו טאָן דאָס איז צו שטעלן די מאַקסימום פיילז סעטטינגס.

ב) מיר געדענקט אַז אין אנדערע פראיעקטן מיר נוצן אַ מאָדולע וואָס אַלאַוז אונדז צו טאָן הינטערגרונט געזונט טשעקס - אַקאָרדינגלי, מיר האָבן גאַנץ אָפט געזונט טשעקס אַזוי אַז דאַונטיים אין די געשעעניש פון אַ צופאַל וואָלט זיין מינימאַל.

צום באַדויערן, דאָס איז אויך נישט אַלע, ווייַל ממש די ערשטער צוויי וואָכן פון אָפּעראַציע פון ​​דעם סכעמע געוויזן אַז TCP געזונט טשעק איז אויך אַ אַנרילייאַבאַל זאַך: אויף די אַפּסטרים סערווער עס קען נישט זיין Nginx, אָדער Nginx אין D-שטאַט, און אין אין דעם פאַל, דער קערן וועט אָננעמען די קשר, געזונט טשעק וועט פאָרן, אָבער וועט נישט אַרבעטן. דעריבער, מיר מיד ריפּלייסט דעם מיט געזונט-טשעק http, געמאכט אַ ספּעציפיש איינער, וואָס, אויב עס קערט 200, אַלץ אַרבעט אין דעם שריפט. איר קענען טאָן נאָך לאָגיק - למשל, אין די פאַל פון קאַטשינג סערווערס, קאָנטראָלירן אַז די טעקע סיסטעם איז מאָונטעד ריכטיק:

און דאָס וואָלט פּאַסן אונדז, אַחוץ אַז אין דעם מאָמענט די קרייַז גאָר ריפּיטיד וואָס די ייַזנוואַרג האט. אבער מיר געוואלט צו טאָן בעסער. ביז אַהער, מיר האָבן איין באַקאַפּ סערווער, און דאָס איז מיסטאָמע נישט זייער גוט, ווייַל אויב איר האָבן אַ הונדערט סערווערס, ווען עטלעכע דורכפאַל אין אַמאָל, איין באַקאַפּ סערווער איז אַנלייקלי צו קאָפּע מיט די מאַסע. דעריבער, מיר באַשלאָסן צו פאַרשפּרייטן די רעזערוואַציע איבער אַלע סערווערס: מיר פשוט געמאכט אן אנדער באַזונדער אַפּסטרים, געשריבן אַלע סערווערס דאָרט מיט זיכער פּאַראַמעטערס אין לויט מיט די מאַסע זיי קענען דינען, צוגעלייגט די זעלבע געזונט טשעקס וואָס מיר האָבן פריער:

זינט עס איז אוממעגלעך צו גיין צו אן אנדער אַפּסטרים אין איין אַפּסטרים, עס איז נייטיק צו מאַכן זיכער אַז אויב די הויפּט אַפּסטרים, אין וואָס מיר נאָר רעקאָרדעד די ריכטיק, נויטיק פאָטאָ קאַש, איז ניט בנימצא, מיר פשוט דורכגעגאנגען דורך די טעות_פּאַגע צו פאַלבאַק, פֿון ווו מיר געגאנגען צו די באַקאַפּ אַפּסטרים:

און דורך ממש אַדינג פיר סערווערס, דאָס איז וואָס מיר האָבן: מיר ריפּלייסט טייל פון די מאַסע - מיר אַוועקגענומען עס פון LTM צו די סערווערס, ימפּלאַמענאַד די זעלבע לאָגיק דאָרט, ניצן נאָרמאַל ייַזנוואַרג און ווייכווארג, און גלייך באקומען די באָנוס אַז די סערווערס קענען זיין סקיילד, ווייַל זיי קענען זיין פשוט צושטעלן ווי פיל ווי דארף. נו, דער בלויז נעגאַטיוו איז אַז מיר האָבן פאַרלאָרן הויך אַוויילאַבילאַטי פֿאַר פונדרויסנדיק ניצערס. אבער אין דעם מאָמענט מיר האָבן צו קרבן דעם, ווייַל עס איז נייטיק צו סאָלווע די פּראָבלעם מיד. אזוי, מיר האבן אראפגענומען א טייל פון די לאסט, עס איז דעמאלט געווען בערך 40%, LTM האט זיך געפילט גוט, און ממש צוויי וואכן נאכדעם וואס דער פראבלעם האט זיך אנגעהויבן, האבן מיר אנגעהויבן שיקן נישט 45 ק פארלאנגען פּער סעקונדע, נאר 55 ק. אין פאַקט, מיר געוואקסן מיט 20% - דאָס איז קלאר דער פאַרקער וואָס מיר האָבן נישט געגעבן צו דער באַניצער. און נאָך דעם, זיי אנגעהויבן צו טראַכטן וועגן ווי צו סאָלווע די רוען פּראָבלעם - צו ענשור הויך פונדרויסנדיק אַקסעסאַביליטי.

מיר האָבן עטלעכע פּויזע, בעשאַס וואָס מיר דיסקאַסט וואָס לייזונג מיר וואָלט נוצן פֿאַר דעם. עס זענען געווען פּראַפּאָוזאַלז צו ענשור רילייאַבילאַטי ניצן דנס, ניצן עטלעכע היים-געשריבן סקריפּס, דינאַמיש רוטינג פּראָטאָקאָלס ... עס זענען געווען פילע אָפּציעס, אָבער עס איז שוין קלאָר אַז פֿאַר באמת פאַרלאָזלעך עקספּרעס פון פאָטאָס, איר דאַרפֿן צו באַקענען אן אנדער שיכטע וואָס וועט מאָניטאָר דעם . מיר גערופן די מאשינען פאָטאָ דירעקטאָרס. די ווייכווארג וואָס מיר רילייד אויף איז Keepalved:

צו אָנהייבן מיט, וואָס באשטייט Keepalive? דער ערשטער איז די VRRP פּראָטאָקאָל, וויידלי באקאנט צו נעטוואָרקערס, ליגן אויף נעץ ויסריכט וואָס גיט שולד טאָלעראַנץ צו די פונדרויסנדיק IP אַדרעס צו וואָס קלייאַנץ פאַרבינדן. דער צווייטער טייל איז IPVS, IP ווירטואַל סערווער, פֿאַר באַלאַנסינג צווישן פאָטאָ ראָוטערס און ינשורינג שולד טאָלעראַנץ אויף דעם מדרגה. און דריט - געזונט טשעקס.

לאָמיר אָנהייבן מיט דער ערשטער טייל: VRRP - ווי אַזוי עס קוקט? עס איז אַ זיכער ווירטואַל IP, וואָס האט אַן פּאָזיציע אין די dns badoocdn.com, ווו קלייאַנץ פאַרבינדן. אין עטלעכע פונט אין צייט, מיר האָבן אַן IP אַדרעס אויף איין סערווער. קעפּאַליוועד פּאַקיץ לויפן צווישן די סערווערס ניצן די VRRP פּראָטאָקאָל, און אויב דער בעל פארשווינדט פון די ראַדאַר - דער סערווער איז רעבאָאָטעד אָדער עפּעס אַנדערש, דער באַקאַפּ סערווער אויטאָמאַטיש פּיקס אַרויף דעם IP אַדרעס - קיין מאַנואַל אַקשאַנז זענען פארלאנגט. דער חילוק צווישן בעל און באַקאַפּ איז דער הויפּט בילכערקייַט: די העכער עס איז, די גרעסער די געלעגנהייַט אַז די מאַשין וועט ווערן אַ בעל. א זייער גרויס מייַלע איז אַז איר טאָן ניט דאַרפֿן צו קאַנפיגיער IP אַדרעסעס אויף די סערווער זיך, עס איז גענוג צו באַשרייַבן זיי אין די קאַנפיגיעריישאַן, און אויב די IP אַדרעסעס דאַרפֿן עטלעכע מנהג רוטינג כּללים, דאָס איז דיסקרייבד גלייַך אין די קאָנפיג. דער זעלביקער סינטאַקס ווי דיסקרייבד אין די VRRP פּעקל. איר וועט ניט טרעפן קיין אַנפאַמיליער זאכן.

וואָס טוט דאָס קוק ווי אין פיר? וואָס כאַפּאַנז אויב איינער פון די סערווערס פיילז? ווי באַלד ווי דער בעל פארשווינדט, אונדזער באַקאַפּ סטאַפּס צו באַקומען אַדווערטייזמאַנץ און אויטאָמאַטיש ווערן אַ בעל. נאָך עטלעכע מאָל, מיר ריפּערד די בעל, רעבאָאָטעד, אויפשטיין Keepalved - אַדווערטייזמאַנץ קומען מיט אַ העכער בילכערקייַט ווי די באַקאַפּ, און די באַקאַפּ אויטאָמאַטיש טורנס צוריק, רימוווז IP אַדרעסעס, קיין מאַנואַל אַקשאַנז דאַרפֿן צו זיין געטאן.

אזוי, מיר האָבן ינשורד די שולד טאָלעראַנץ פון די פונדרויסנדיק IP אַדרעס. דער ווייַטער טייל איז צו עפעס באַלאַנסירן די פאַרקער פון די פונדרויסנדיק IP אַדרעס צו די פאָטאָ ראָוטערס וואָס זענען שוין טערמאַנייטינג עס. אַלץ איז גאַנץ קלאָר מיט די באַלאַנסינג פּראָטאָקאָלס. דאָס איז אָדער אַ פּשוט ראָונד-ראָבין, אָדער אַ ביסל מער קאָמפּליצירט זאכן, וורר, רשימה קשר און אַזוי אויף. דאָס איז בייסיקלי דיסקרייבד אין די דאַקיומענטיישאַן, עס איז גאָרנישט ספּעציעל. אבער די עקספּרעס אופֿן ... דאָ מיר וועלן נעמען אַ נעענטער קוק אין וואָס מיר אויסדערוויילט איינער פון זיי. די זענען NAT, דירעקט רוטינג און TUN. דער פאַקט איז אַז מיר גלייך פּלאַננעד צו צושטעלן 100 גיגאבייט פון פאַרקער פֿון די זייטלעך. אויב איר אָפּשאַצן, איר דאַרפֿן 10 גיגאַביט קאַרדס, רעכט? 10 גיגאַביט קאַרדס אין איין סערווער איז שוין ווייַטער פון די פאַרנעם פון, לפּחות, אונדזער באַגריף פון "נאָרמאַל ויסריכט". און דעמאָלט מיר דערמאנט אַז מיר טאָן ניט נאָר געבן אַוועק עטלעכע פאַרקער, מיר געבן אַוועק פאָטאָס.

וואָס איז ספּעציעל? - ריזיק חילוק צווישן ינקאַמינג און אַוטגאָוינג פאַרקער. ינקאַמינג פאַרקער איז זייער קליין, אַוטגאָוינג פאַרקער איז זייער גרויס:

אויב איר קוק אין די גראַפיקס, איר קענען זען אַז אין דעם מאָמענט דער דירעקטאָר נעמט וועגן 200 מב פּער סעקונדע, דאָס איז אַ זייער פּראָסט טאָג. מיר געבן צוריק 4,500 מעגאבייטן פּער סעקונדע, אונדזער פאַרהעלטעניש איז בעערעך 1/22. עס איז שוין קלאָר אַז צו גאָר צושטעלן אַוטגאָוינג פאַרקער צו 22 אַרבעטער סערווערס, מיר נאָר דאַרפֿן איינער וואָס אַקסעפּץ דעם קשר. דאָס איז ווו די דירעקט רוטינג אַלגערידאַם קומט צו אונדזער הילף.

וויאַזוי קוקט עס אויס? אונדזער פאָטאָ דירעקטאָר, לויט זיין טיש, טראַנסמיטט קאַנעקשאַנז צו פאָטאָ ראָוטערס. אָבער פאָטאָ ראָוטערס שיקן צוריק פאַרקער גלייך צו דער אינטערנעץ, שיקן עס צו דער קליענט, עס טוט נישט גיין צוריק דורך די פאָטאָ דירעקטאָר, אַזוי, מיט אַ מינימום נומער פון מאשינען, מיר ענשור גאַנץ שולד טאָלעראַנץ און פּאַמפּינג פון אַלע פאַרקער. אין די קאָנפיגס עס קוקט ווי דאָס: מיר ספּעציפיצירן די אַלגערידאַם, אין אונדזער פאַל עס איז אַ פּשוט רר, צושטעלן די דירעקט רוטינג אופֿן און דעמאָלט אָנהייבן צו רשימה אַלע פאַקטיש סערווערס, ווי פילע פון ​​זיי מיר האָבן. וואָס וועט באַשטימען דעם פאַרקער. אויב מיר האָבן איין אָדער צוויי מער סערווערס דאָרט, אָדער עטלעכע סערווערס, אַזאַ אַ נויט ערייזאַז - מיר נאָר לייגן דעם אָפּטיילונג צו די קאַנפיגיעריישאַן און טאָן ניט זאָרג צו פיל. פֿון דער זייַט פון פאַקטיש סערווערס, פֿון די פאָטאָ ראַוטער זייַט, דעם אופֿן ריקווייערז די מערסט מינימאַל קאַנפיגיעריישאַן, עס איז בישליימעס דיסקרייבד אין די דאַקיומענטיישאַן, און עס זענען קיין פּיטפאָלז.

וואָס איז ספּעציעל פייַן איז אַז אַזאַ אַ לייזונג טוט נישט מיינען אַ ראַדיקאַל רידיזיין פון די היגע נעץ; דאָס איז געווען וויכטיק פֿאַר אונדז; מיר האָבן צו סאָלווע דעם מיט מינימאַל קאָס. אויב איר קוק בייַ IPVS אַדמין באַפֿעל רעזולטאַט, דעמאָלט מיר וועלן זען ווי עס קוקט ווי. דאָ מיר האָבן אַ זיכער ווירטואַל סערווער, אויף פּאָרט 443, ליסאַנז, אַקסעפּץ די קשר, אַלע ארבעטן סערווערס זענען ליסטעד, און איר קענען זען אַז די קשר איז, געבן אָדער נעמען, די זעלבע. אויב מיר קוקן אין די סטאַטיסטיק אויף דער זעלביקער ווירטואַל סערווער, מיר האָבן ינקאַמינג פּאַקיץ, ינקאַמינג קאַנעקשאַנז, אָבער לעגאַמרע קיין אַוטגאָוינג אָנעס. אַוטגאָוינג קאַנעקשאַנז גיין גלייַך צו דער קליענט. אָוקיי, מיר זענען ביכולת צו אַנבאַלאַנסט עס. איצט, וואָס כאַפּאַנז אויב איינער פון אונדזער פאָטאָ ראָוטערס פיילז? נאָך אַלע, אייַזן איז אייַזן. עס קען גיין אין קערנעל פּאַניק, עס קען ברעכן, די מאַכט צושטעלן קען ברענען אויס. עפּעס. דאָס איז וואָס געזונט טשעקס זענען דארף. זיי קענען זיין אַזוי פּשוט ווי קאָנטראָלירן ווי די פּאָרט איז אָפן, אָדער עפּעס מער קאָמפּליצירט, ביז עטלעכע היים-געשריבן סקריפּס וואָס אפילו קאָנטראָלירן די געשעפט לאָגיק.

מיר פארשטאפט ערגעץ אין די מיטל: מיר האָבן אַ https בעטן צו אַ ספּעציפיש אָרט, דער שריפט איז גערופן, אויב עס ריספּאַנדז מיט אַ 200 ענטפער, מיר גלויבן אַז אַלץ איז גוט מיט דעם סערווער, אַז עס איז לעבעדיק און קענען זיין אויסגעדרייט אויף גאַנץ לייכט.

ווי אַזוי קוקט דאָס, ווידער, אין פיר? זאל ס קער אַוועק די סערווער פֿאַר וישאַלט - פלאַשינג די בייאָוס, פֿאַר בייַשפּיל. אין די לאָגס, מיר מיד האָבן אַ טיימאַוט, מיר זען די ערשטער שורה, און נאָך דריי פרווון עס איז אנגעצייכנט ווי "ניט אַנדערש", און עס איז פשוט אַוועקגענומען פון דער רשימה.

א צווייטע אָפּפירונג אָפּציע איז אויך מעגלעך, ווען VS איז פשוט שטעלן צו נול, אָבער אויב די פאָטאָ איז אומגעקערט, דאָס טוט נישט אַרבעטן געזונט. דער סערווער קומט ארויף, נגינקס הייבט זיך אן דארט, געזונט-טשעק פארשטייט גלייך אז דער קשר ארבעט, אז אלעס איז גוט, און דער סערווער איז ארויס אין אונזער ליסטע, און די לאד הייבט זיך גלייך אויף אים. קיין מאַנואַל אַקשאַנז זענען פארלאנגט פון די פליכט אַדמיניסטראַטאָר. דער סערווירער רעבאָאָטעד בייַ נאַכט - די מאָניטאָרינג אָפּטיילונג טוט נישט רופן אונדז וועגן דעם בייַ נאַכט. זיי מיטטיילן איר אַז דאָס געטראפן, אַלץ איז גוט.

אַזוי, אין אַ פערלי פּשוט וועג, מיט די הילף פון אַ קליין נומער פון סערווערס, מיר סאַלווד די פּראָבלעם פון פונדרויסנדיק שולד טאָלעראַנץ.

עס בלייבט נאָר צו זאָגן, אַז דאָס אַלץ דאַרף, פֿאַרשטייט זיך, מאָניטאָרירט ווערן. סעפּעראַטלי, עס זאָל זיין באמערקט אַז Keepalivede, ווי ווייכווארג געשריבן אַ לאַנג צייַט צוריק, האט אַ פּלאַץ פון וועגן צו מאָניטאָר עס, ביידע מיט טשעקס דורך DBus, SMTP, SNMP און נאָרמאַל Zabbix. פּלוס ער אַליין ווייסט ווי צו שרייַבן אותיות פֿאַר כּמעט יעדער ניסן, און צו זיין ערלעך, אין עטלעכע פונט מיר אַפֿילו געדאַנק פון קער אַוועק, ווייַל ער שרייבט אַ פּלאַץ פון אותיות פֿאַר קיין פאַרקער סוויטשינג, סוויטשינג אויף, פֿאַר יעדער IP קשר, און אזוי ווייטער . פון קורס, אויב עס זענען אַ פּלאַץ פון סערווערס, איר קענען אָוווערוועלם זיך מיט די אותיות. מיר מאָניטאָר nginx אויף פאָטאָ ראָוטערס ניצן נאָרמאַל מעטהאָדס, און ייַזנוואַרג מאָניטאָרינג איז נישט ניטאָ. מיר וואָלט, פון קורס, רעקאָמענדירן צוויי מער זאכן: ערשטער, פונדרויסנדיק געזונט-טשעקס און אַוויילאַבילאַטי, ווייַל אפילו אויב אַלץ אַרבעט, אין פאַקט, טאָמער יוזערז באַקומען נישט פאָטאָס רעכט צו פּראָבלעמס מיט פונדרויסנדיק פּראַוויידערז אָדער עפּעס מער קאָמפּליצירט. עס איז שטענדיק ווערט צו האַלטן ערגעץ אויף אן אנדער נעץ, אין אַמאַזאָן אָדער ערגעץ אַנדערש, אַ באַזונדער מאַשין וואָס קענען פּינג דיין סערווערס פון די אַרויס, און עס איז אויך ווערט צו נוצן אָדער אַנאַמאַלי דיטעקשאַן, פֿאַר די וואס וויסן ווי צו טאָן טריקי מאַשין לערנען, אָדער פּשוט מאָניטאָרינג, אין מינדסטער אין סדר צו שפּור אויב ריקוועס האָבן דראַפּט שארף, אָדער, אויף די פאַרקערט, געוואקסן. עס קען אויך זיין נוציק.

לאָמיר קיצערן: מיר, אין פאַקט, ריפּלייסט די פּרעסן-קלאַד לייזונג, וואָס אין עטלעכע פונט אויפגעהערט צו פּאַסן אונדז, מיט אַ גאַנץ פּשוט סיסטעם וואָס טוט אַלץ די זעלבע, דאָס איז, עס גיט טערמאַניישאַן פון הטטפּס פאַרקער און ווייַטער קלוג רוטינג מיט די נייטיק געזונט טשעקס. מיר האָבן געוואקסן די פעסטקייַט פון דעם סיסטעם, דאָס איז, מיר נאָך האָבן אַ הויך אַוויילאַבילאַטי פֿאַר יעדער שיכטע, פּלוס מיר האָבן די באָנוס אַז עס איז גאַנץ גרינג צו וואָג עס אַלע אויף יעדער שיכטע, ווייַל עס איז נאָרמאַל ייַזנוואַרג מיט נאָרמאַל ווייכווארג. , מיר האָבן סימפּלאַפייד דיאַגנאָסינג מעגלעך פּראָבלעמס.

מיט וואס האבן מיר געענדיגט? מיר האָבן אַ פּראָבלעם בעשאַס די יאנואר האָלידייַס פון 2018. אין די ערשטע זעקס חדשים, ווען מיר שטעלן דעם סכעמע אין אָפּעראַציע, מיר יקספּאַנדיד עס צו אַלע פאַרקער אין סדר צו באַזייַטיקן אַלע פאַרקער פון LTM, מיר געוואקסן בלויז אין פאַרקער אין איין דאַטן צענטער פון 40 גיגאבייט צו 60 גיגאבייט, און אין דער זעלביקער צייט פֿאַר די גאנצע 2018 יאָר זענען ביכולת צו שיקן כּמעט דריי מאָל מער פאָטאָס פּער סעקונדע.

מקור: www.habr.com