هر روز OpenVPN را دوباره راه‌اندازی کنیم؟ خرابی را انتخاب کنید، نه ساعت را
راه‌اندازی مجدد طبق تقویم، نگهداری است نه بازیابی. مشخص کنید که همتا، فرایند یا برنامه از کار افتاده است، سپس آن لایه را با محرک لازم تجهیز کنید.
وظیفه‌ای cron را به ارث می‌برید که هر روز ساعت 04:10 OpenVPN را دوباره راه‌اندازی می‌کند و یک سال است همه چیز را پایدار نگه داشته است. اما تونل سالمی را هم در ساعتی ثابت قطع می‌کند و کاری برای قطعی‌ای که واقعاً هنگام ناهار رخ می‌دهد نمی‌کند. راه‌اندازی مجدد طبق تقویم یک تصمیم نگهداری است. بازیابی طراحی دیگری است با محرک مشخص.
سه شکل خرابی به سه مالک متفاوت نیاز دارد. اول خرابی را انتخاب کنید، سازوکار خودش می‌آید.
سه خرابی، سه مالک
تونل می‌تواند بالا باشد در حالی که همتایش رفته است: فرایند اجرا می‌شود، رابط وجود دارد و چیز مفیدی از آن عبور نمی‌کند. فرایند می‌تواند مرده باشد در حالی که همتا سالم است، و آن‌گاه تنها چیزی که آن را آغاز کرده می‌تواند بازش گرداند. برنامه‌ای پشت تونل می‌تواند خراب باشد در حالی که هم تونل و هم همتا سالم‌اند، و راه‌اندازی مجدد سرویس‌گیر در این حالت قطعی را گسترده‌تر می‌کند بی‌آنکه به علت دست بزند. جدا کردن این سه حالت تمام تصمیم است.
هر کدام نشانه و مالک خودش را دارد. زنده‌بودن به پروتکل VPN تعلق دارد، چرخه عمر فرایند به مدیر سرویس، و سلامت برنامه به پایش با اختیار محدود.
یک گزینه زنده‌بودن چه می‌تواند بکند و چه نمی‌تواند
keepalive کمکی است که به زوج ping و ping-restart بسط می‌یابد، همان‌طور که مرجع گزینه‌های پیوند توضیح می‌دهد، و مهلت‌هایی که تولید می‌کند روی سرور و سرویس‌گیر یکسان نیست. مقادیری که سرور هل می‌دهد نیز می‌تواند آنچه سرویس‌گیر محلی تنظیم کرده را بازنویسی کند، و به همین دلیل مهلتی که در یک فایل محلی درست به نظر می‌رسد شاید همان مهلت مؤثر نباشد.
این آن را ابزار درست برای همتای گمشده و ابزار نادرست برای فرایند مرده می‌کند، چون فرایندی که خارج شده نمی‌تواند تایمرهای خودش را اجرا کند. همچنین چیزی درباره پاسخ‌دادن برنامه‌ای پشت تونل نمی‌گوید، چون تبادل میان دو نقطه پایانی VPN رخ می‌دهد. کپی کردن یک زوج مهلت از استقرار دیگری بدون بررسی نقش، قطعی‌های مورد انتظار و رفتار احراز هویت مجدد همان راهی است که یک تونل پایدار شروع به لرزیدن می‌کند.
مدیر سرویس چه چیزی را در اختیار دارد
اگر دیمن خارج شود، مدیری که آن را آغاز کرده تصمیم می‌گیرد بعد چه شود. سیاست راه‌اندازی مجدد مبتنی بر خرابی، با تأخیر و محدودیت نرخ شروع، حلقه فروپاشی را بدون تبدیل آن به بمب انشعاب مدیریت می‌کند. این تنظیمات به نتایج فرایند و مهلت‌ها واکنش می‌دهند و فرایندی را که زنده اما بی‌فایده است تشخیص نمی‌دهند. این شکافی نیست که با سیاستی گسترده‌تر وصله شود؛ این مرز میان چرخه عمر و زنده‌بودن است.
مالکیت به اندازه تنظیمات اهمیت دارد. اتصالی که مدیر شبکه رومیزی آغاز کرده باید ترتیب بازیابی همان مدیر را حفظ کند، و افزودن یک واحد سرویس رقیب برای همان رابط، به یک تونل دو مالک می‌دهد. یکی را انتخاب کنید و بنویسید کدام است.
چه زمانی راه‌اندازی مجدد زمان‌بندی‌شده موجه است
راه‌اندازی مجدد زمان‌دار می‌تواند اقدام نگهداری معقولی باشد: مالک، پنجره، نمونه نام‌دار و راه ورود مستقل دارد. اما نمی‌تواند سیاست کلی قابلیت اطمینان باشد که در ساعتی ثابت همه را هم قطع کند.
اگر راه‌اندازی مجدد برای دور زدن یک نشتی شناخته‌شده یا حالت گیرکرده وجود دارد، این را در توضیح واحد بنویسید، وگرنه نفر بعدی آن را برای همیشه نگه می‌دارد.
موارد مهم را آزمایش کنید: همتا ناپدید می‌شود در حالی که فرایند بالا می‌ماند، فرایند خارج می‌شود، تلاش مجدد به اعتبارنامه تازه نیاز دارد، و تونل برمی‌گردد در حالی که برنامه خراب می‌ماند. ببینید کدام جزء واکنش می‌دهد و چه حالتی بر جا می‌گذارد.
پرسش درست این نیست که چند وقت یک‌بار راه‌اندازی مجدد کنیم، بلکه این است که چه چیزی باید خرابی را اول متوجه شود.