Active-Passive Architecture: הדרך הפשוטה והבטוחה יותר לבנות DR אמיתי
מאת צוות מדיה דיל · 07.08.2026 · DevOps · 6 דק׳
מדריך טכני ל-Active-Passive Architecture: standby regions, RTO/RPO, אסטרטגיות failover (cold/warm/hot standby), ולמה זה עדיין הבחירה הנכונה לרוב הארגונים.
הבעיה: לא כל ארגון צריך (או יכול להרשות לעצמו) Active-Active
Active-Active נשמע כמו ה"פתרון האולטימטיבי" — אבל הוא דורש פתרון אמיתי לכתיבות מקבילות, DB ייעודי או conflict resolution מורכב, ותשתית תפעולית בשלה. רוב הארגונים, גם כאלה עם צרכי DR רציניים, לא צריכים את זה. Active-Passive Architecture נותנת תשובה פשוטה יותר: region אחד (primary) משרת את כל התעבורה בזמן רגיל, region שני (standby) מוכן לקחת עוגן אם ה-primary נופל. הפשטות הזו היא בדיוק הסיבה שהיא עדיין הפתרון הנפוץ ביותר בתעשייה ל-Disaster Recovery ברמת region.
שלוש רמות של Standby: Cold, Warm, Hot
ההבחנה הקריטית ב-active-passive היא לא "יש standby או אין", אלא כמה "חם" ה-standby — וזה קובע ישירות את ה-RTO (Recovery Time Objective, כמה זמן עד שהשירות חוזר):
- Cold Standby — תשתית קיימת רק כ-infrastructure-as-code (Terraform/CloudFormation), לא רצה בפועל. בזמן אסון, מריצים provisioning מלא. RTO: שעות. עלות: הנמוכה ביותר (משלמים כמעט 0 עד שצריך).
- Warm Standby — instances רצים בקנה מידה מוקטן (למשל 20% מהקיבולת של ה-primary), עם דאטה מסונכרן ברציפות. בזמן failover, scale-up מהיר ל-100% ומעבר תעבורה. RTO: דקות בודדות. עלות: בינונית.
- Hot Standby — replica מלא בקנה מידה זהה לproduction, רץ כל הזמן, מוכן לקבל 100% מהתעבורה מיידית. RTO: שניות עד דקה בודדת (בעיקר הזמן שלוקח ל-DNS/load balancer failover לקרות). עלות: הגבוהה ביותר — כמעט זהה ל-active-active מבחינת תשתית, רק בלי לשרת traffic בפועל.
הבחירה בין השלוש היא בעצם החלטה עסקית: כמה RTO אתם מוכנים לסבול מול כמה אתם מוכנים לשלם על capacity שרוב הזמן לא בשימוש.
RPO: כמה דאטה מותר לאבד
מדד קריטי שני, בנפרד מ-RTO, הוא RPO (Recovery Point Objective) — כמה דאטה (נמדד בזמן) מותר לאבד בין הכתיבה האחרונה שהצליחה ב-primary לבין נקודת ה-failover. RPO נקבע ישירות על ידי אסטרטגיית ה-replication:
- Synchronous replication בין regions — RPO=0 (אין אובדן דאטה בכלל), אבל latency כתיבה גבוה מאוד (הכתיבה מחכה לאישור מregion מרוחק) — לרוב לא מעשי ל-multi-region בגלל מרחק פיזי, אלא אם ה-regions קרובים גיאוגרפית.
- Asynchronous replication — RPO בגודל של שניות עד דקות, תלוי בtag/lag בין regions. הפתרון המעשי הנפוץ ביותר ל-active-passive cross-region.
- Snapshot-based backup — RPO בגודל שעות (תלוי בתדירות ה-snapshot). מתאים רק לworkloads שלא רגישים לאובדן דאטה משמעותי.
העיקרון החשוב: RTO ו-RPO הם שני מדדים נפרדים לגמרי, וצריך לקבוע יעד לכל אחד בנפרד לפי דרישת ה-business, לא להניח שאחד "פותר" את השני.
מנגנון ה-Failover: מי מחליט, ומתי
שאלה תפעולית מרכזית: failover אוטומטי או ידני? יש trade-off אמיתי:
- Automatic Failover — health check מזהה שה-primary לא זמין (לרוב אחרי כמה בדיקות רצופות כושלות, כדי למנוע false positive מ-network blip רגעי) ומפעיל את ה-standby אוטומטית. מהיר, אבל מסוכן — false positive (למשל network partition זמני בלי כשל אמיתי) יכול לגרום ל-failover מיותר, ואפילו ל-split-brain אם ה-primary בעצם עדיין חי אבל לא נגיש רגעית.
- Manual Failover with Automated Tooling — המערכת מזהה ומתריעה, אבל אדם מאשר את ה-failover בפועל (לרוב בלחיצת כפתור על runbook מוכן מראש). איטי יותר (תלוי בזמינות בן אדם) אבל בטוח יותר מפני false positives.
הפרקטיקה הנפוצה בארגונים בוגרים: automatic failover רק לתרחישים חד-משמעיים (region שלם down לפי סטטוס רשמי של הספק), manual עם tooling מהיר לכל שאר המקרים המעורפלים יותר.
DNS Failover: הפרט הקטן שהורס RTO
נקודה שמפילה הרבה תוכניות DR טובות על הנייר: מעבר תעבורה בפועל תלוי לרוב ב-DNS record change, וDNS TTL (Time To Live) שנשאר גבוה (שעה, יום) אומר שגם אם ה-failover הטכני קרה מיידית, לקוחות שכבר cache-ו את ה-IP הישן ימשיכו לפנות אליו עד שה-TTL יפוג. הפתרון: TTL נמוך (30-60 שניות) לרשומות ה-DNS הקריטיות, ובעדיפות — שימוש ב-Anycast IP או global load balancer (AWS Global Accelerator, Cloudflare Load Balancing) שלא תלוי ב-DNS caching בכלל ומבצע את ה-switch ברמת הרשת עצמה.
Trade-offs: עלות Standby מול מהירות התאוששות
ה-trade-off המרכזי הוא ליניארי למדי: ככל שה-standby "חם" יותר (מ-cold ל-hot), RTO יורד אבל העלות עולה. ההחלטה הנכונה תלויה בעלות בפועל של downtime לעסק — אם כל דקת downtime עולה אלפי דולרים (e-commerce בקנה מידה, פלטפורמת תשלומים), hot standby מוצדק כלכלית. אם downtime של שעה הוא מטריד אבל לא הרסני (SaaS B2B פנימי), warm או אפילו cold standby הגיוני יותר כלכלית.
Runbook ל-Failover: לא להמציא תחת לחץ
גם עם automatic failover, כדאי שיהיה runbook ידני מתועד ומעודכן — למקרים שבהם ה-automation עצמה נכשלת, או שההחלטה דורשת שיקול דעת אנושי (למשל, האם ה-primary "באמת" נפל או שזה false positive מ-network blip). runbook טוב ל-failover כולל: רשימת בדיקות מוקדמות לוודא שה-standby אכן מוכן (replication lag תקין, secrets מסונכרנים, גרסת קוד תואמת), סדר הפעולות המדויק (DNS switch, activation של ה-standby, אימות health), ותוכנית rollback אם ה-failover עצמו נכשל באמצע.
נקודה שקל לפספס: runbook ל-failover אל ה-standby הוא רק חצי מהתמונה. צריך גם runbook ל-failback — החזרת התעבורה ל-primary המקורי אחרי שהוא מתאושש, כולל resync של כל הדאטה שהצטבר ב-standby בזמן שהוא שירת תעבורה. failback שלא מתוכנן מראש עלול לגרום לאובדן דאטה משמעותי בדיוק ברגע ש"חושבים שהכול כבר נגמר".
טעויות נפוצות בפרודקשן
- Standby שלא נבדק — הטעות הכי נפוצה בכל הנושא: standby שקיים "על הנייר" (או אפילו רץ) אבל אף פעם לא עבר failover test אמיתי, ומתגלה כשבור בדיוק כשצריך אותו (secrets לא מסונכרנים, migration DB שלא רץ, IAM permissions חסרות).
- DNS TTL גבוה מדי — RTO "תיאורטי" של דקה הופך לRTO אמיתי של שעה בגלל caching.
- אין drift detection בין primary ל-standby — קונפיגורציה, secrets, וגרסאות תוכנה שמתפצלות בהדרגה בין הסביבות בלי שמישהו שם לב, עד שה-failover בפועל חושף פערים.
- Replication lag לא מנוטר — אם ה-async replication מפגר משמעותית מאחורי ה-primary בלי alert, RPO בפועל גבוה בהרבה מהיעד המוצהר.
Cost Optimization: להוזיל את מחיר ה-Standby בלי לוותר על RTO
לצוותים שרגישים לעלות, יש כמה טכניקות מוכחות להוזיל hot/warm standby בלי לוותר על יעד RTO: auto-scaling מבוסס-אירוע — ה-standby רץ ב-warm capacity, אבל מוגדר עם auto-scaling policy שמופעל אוטומטית ברגע שה-health check על ה-primary מזהה בעיה, ומגיע ל-full capacity תוך דקה-שתיים, לא ממתין לwarm-up ידני. שימוש ב-Spot/Preemptible instances לחלק מקיבולת ה-standby (לא לתפקידים קריטיים כמו ה-DB עצמו, אבל לshims של compute stateless) — מוזיל משמעותית את עלות ה"המתנה" תוך שמירה על יכולת scale-up מהירה. Reserved capacity משותפת בין primary לstandby כשהם ב-cloud provider עם תמיכה בזה — חלק מהקיבולת המוזמנת "זזה" בין regions לפי הצורך במקום להיות מוקצית קשיח.
הטכניקות האלה לא מתאימות לכל שכבה — ה-database layer, למשל, כמעט תמיד דורש capacity יציב ולא spot, כי אובדן instance באמצע replication הוא סיכון לא שקול. אבל לשכבת ה-application (compute stateless) יש הרבה מרחב תמרון להוזיל בלי לפגוע ב-RTO בפועל.
מתי כן ומתי לא
Active-Passive הוא הבחירה הנכונה לרוב מוצרי ה-SaaS וה-Enterprise שצריכים DR רציני אבל לא בסיס משתמשים גלובלי פעיל שדורש latency אופטימלי מכל אזור. הוא גם צעד ראשון הגיוני לפני מעבר ל-active-active — קל יותר לבנות ולתחזק, ונותן את רוב הערך של "לשרוד נפילת region" בלי המורכבות של conflict resolution.
DR Drills: ההבדל בין תוכנית DR לתאוריית DR
הפער הכי גדול שראינו בין ארגונים שה-DR שלהם עבד בפועל לבין כאלה שהתרסק בדיוק כשהיה צריך אותו הוא לא איכות התכנון — הוא תדירות התרגול. תוכנית DR שנכתבה לפני שנה ולא נבדקה מאז היא כמעט תמיד שגויה בפרטים קריטיים: secrets שהתחלפו ולא סונכרנו ל-standby, migration סכמה שרץ רק ב-primary, גרסת runtime שהתעדכנה ב-primary אבל לא ב-standby. DR drill — failover מתוזמן ומכוון לסביבת staging (או אפילו production, בזמן שפל, עם צוות מוכן) — הוא הדרך היחידה לגלות את הפערים האלה לפני שהם קורים תחת לחץ אמיתי.
תדירות מומלצת: DR drill מלא (כולל failover בפועל ומדידת RTO/RPO אמיתיים, לא רק תיאורטיים) לפחות פעם ברבעון עבור מערכות קריטיות, עם בדיקה מהירה יותר (validation שה-standby מסונכרן ומוכן, בלי failover מלא) על בסיס חודשי. חברות שעומדות בדרישות SOC 2 או ISO 27001 לרוב נדרשות ממילא לתעד DR drills באופן שוטף — זו לא רק best practice טכני אלא גם דרישת compliance מפורשת.
סיכום
Active-Passive Architecture נותנת DR אמיתי בעלות ומורכבות נמוכות משמעותית מ-Active-Active. ההחלטות המרכזיות הן רמת ה-"חום" של ה-standby (cold/warm/hot) לפי יעד RTO, אסטרטגיית replication לפי יעד RPO, ומנגנון failover (אוטומטי מול ידני) — וכל זה חסר ערך אם ה-standby לא נבדק בפועל בקביעות דרך DR drills אמיתיים.
תגיות: Active-Passive · Disaster Recovery · RTO · RPO · Failover · Standby · DNS Failover