keepalive во OpenVPN или restart во systemd: што го враќа тунелот?
Тивок соговорник, мртов процес и неупотреблива апликација се три различни дефекти. Дајте го keepalive на OpenVPN, процесот на systemd, и тестирајте го секој случај.
Три различни работи можат да тргнат наопаку со тунел, и тие бараат три различни реакции. Соговорникот престанува да одговара, демонскиот процес умира или апликацијата зад тунелот престанува да служи. Конфигурација што ја рестартира услугата при било која од нив не е внимателен надзор; тоа е едно грубо дејство применето на неповрзани дефекти. Споредбата на тоа што секој механизам навистина може да го набљудува го прави поделбата на работата очигледна.
Три дефекти што изгледаат како еден
Тишината на соговорникот значи дека другиот крај престанал да праќа, и OpenVPN може сам да го открие тоа, бидејќи го поседува отчукувањето. Смртта на процесот значи дека демонот излегол, што управителот на услуги го забележува, а OpenVPN не може. Дефектот на апликацијата значи дека тунелот е во ред, а нешто зад него не е, и ниту еден од другите два механизми нема начин тоа да го знае. Секој бара поинаква реакција, и ниту еден не е исто како забележување дека тунелот работи.
Ова се различни сигнали од различни слоеви, и секој има сопственик што може да дејствува без погодување. Нивното мешање создава систем што се рестартира на симптоми што не може да ги протолкува.
Запишете ги трите случаи пред да смените кој било тајмер. Самиот список обично покажува дека од еден механизам се бара да ги покрие сите три.
Во што всушност се шири keepalive
Директивата keepalive е кратенка, и ширењето се разликува по режим. На сервер, keepalive 10 60 станува локален ping на секои десет секунди, локален рок за рестартирање од 120 секунди и вредности 10 и 60 што се праќаат до клиентите. Рокот на серверот намерно се удвојува за да добие клиентот можност да се рестартира пред серверот да се откаже. Читајте ја проширената форма во конфигурацијата што работи, а не кратенката во профилот.
Токму тоа удвојување е причината зошто секој опис што тврди дека двата краја се рестартираат по шеесет секунди е погрешен. Тоа објаснува и зошто двата краја не нишат во чекор кога патеката се влошува.
Отчукувањето е сообраќај на соговорници на OpenVPN, не ICMP проверка на некој јавен домаќин. Одговорот докажува само дека далечниот крај на тунелот е жив. Тој не кажува ништо за базата на податоци или веб-услугата што на корисникот навистина му треба.
Што не следи Restart=on-failure
Прочитајте ја инсталираната единица пред да додадете заменување. Restart=on-failure реагира на документирани услови за дефект на процесот, што не е исто како следење на состојбата на врската. Не се активира затоа што започнало внатрешно повторно поврзување, и чистото излегување има поинакво значење од пад.
Таа разлика е важна бидејќи внатрешното рестартирање го одржува истиот процес жив. Единицата не гледа ништо, тунелот сам се опоравува, и тоа е точниот исход.
Поставете ги RestartSec и ограничувањата за стартување намерно, инаку циклусот на падови ќе го удри порталот и ќе ја закопа вистинската грешка под пораките за рестартирање. Активираното ограничување за рестартирање ја остава единицата во дефект, што е видливо, додека неограничениот циклус не е.
ping-restart и ping-exit не се заменливи
ping-restart го активира внатрешното рестартирање на OpenVPN и го задржува процесот. ping-exit го завршува процесот при ист вид рок, што ја предава одлуката на управителот на услуги. Тие меѓусебно се исклучуваат, и изборот на вториот менува кому му припаѓа опоравувањето. Разликата е кој одлучува да се обиде повторно, и колку состојба преживува обидот.
Ако изберете излез при истек на рокот, на единицата ѝ требаат соодветна политика за рестартирање и обработка на излезната состојба, инаку дефектот на живост изгледа како трајно запирање. Опциите за постојаност можат да ги зачуваат интерфејсите и рутите низ внатрешно рестартирање, но не и низ излез на процесот.
Изберете еден животен циклус на распоредување и запишете зошто. Профил што ги носи двете директиви е профил што не одлучил.
Тестирајте го секој дефект како свој случај
Симулирајте тивок соговорник, убиен демон и недостапна апликација во одобрен прозорец, потоа проверете кое опоравување се активирало. Тивкиот соговорник треба да создаде внатрешно повторно поврзување, убиениот процес рестартирање на единицата, а прекинот на апликацијата ниту едно од тие. Кога два случаи даваат исто дејство, сопственоста е сѐ уште измешана.
Повтореното опоравување исто така не е поправка. Одбиените акредитиви или два клиенти што делат едно ефективно име ќе продолжат да се заменуваат, а побрзите тајмери само го забрзуваат тоа нишање.