סוכני שכפול push ו-pull דרך VPN בין אתרים

מיקום הסוכן, ולא מיקום הנתונים, הוא ההחלטה שמעצבת מינוי SQL Server. המחשב שמריץ את הסוכן פותח את החיבור, פועל תחת חשבון מסוים ונושא באחריות כשהסנכרון נתקע. ב-VPN בין אתרים ההבדל הזה הוא התכנון, לא פרט. שרטטו את חיבורי הסוכן לפני שתשרטטו את הרשת.

שלושה תפקידים, ולא שניים

ה-Publisher מחזיק בנתוני המאמר, ה-Distributor מחזיק במסד נתוני ההפצה, וה-Subscriber מקבל שינויים. סוכן Log Reader פועל ב-Distributor עבור שכפול טרנזקציוני. סוכן ההפצה הוא זה שמיקומו משתנה עם סוג המינוי, ולכן הוא קובע את תכנון הרשת. סדרו את התפקידים האלה לפני שתדברו על כללי VPN.

מינוי push מריץ את סוכן ההפצה ב-Distributor, ומינוי pull מריץ אותו ב-Subscriber, כפי שמתאר תיעוד המינויים של Microsoft. כל מה בשיחת הרשת נובע מכך שמדובר במחשב כזה או אחר. רשמו ארבע עובדות לכל מינוי: המארח של הסוכן, זהות התהליך שלו, הכניסות למסד הנתונים שבהן הוא משתמש והמשאבים שעליו להגיע אליהם. העובדות האלה, ולא חץ בשרטוט, אומרות לכם איזה כיוון חייב לעבוד.

push פירושו שהסוכן חי ב-Distributor

במינוי push, ה-Distributor פותח את החיבור אל ה-Subscriber דרך ה-VPN. המאזין, חומת האש וכניסת ה-SQL בצד המנוי חייבים לקבל חיבורים שמגיעים מהצד המרוחק. חשבון השירות של ה-Distributor זקוק גם הוא להרשאה במסד הנתונים של המנוי. תכננו את נתיב הכניסה הזה לפני יצירת המינוי, כי גילוי שלו בדיעבד בדרך כלל פירושו יצירתו מחדש.

מסירת תמונת מצב מוסיפה נתיב ששכפול יציב אינו משתמש בו לעולם. אם תמונת המצב מונחת בנתיב שיתוף קבצים, סוכן ההפצה קורא מאותו שיתוף וחשבון המנוי חייב להגיע לאותו נתיב UNC. זרימת שינויים שנמשכת שבועות אינה אומרת דבר על כך אם אתחול מחדש יעבוד. לכן שיתוף תמונת המצב שייך לתוכנית מההתחלה.

אל תקראו push כתעבורה חד-כיוונית. הסוכן זקוק לתשובות, לאישורים ולהחלפות אימות משלו. הנתיב חייב להיות דו-כיווני ברמת החיבור גם כשהנתונים נעים בכיוון אחד.

pull פירושו שהסוכן חי ב-Subscriber

מינוי pull הופך את החיבור: ה-Subscriber מריץ את סוכן ההפצה ופונה אל ה-Distributor. הסדר הזה מתאים למדיניות VPN שמתירה חיבורים יוצאים מהסניף וחוסמת חיבורים נכנסים. הוא גם שם את החלטת התזמון בידי מי שמטפל בשרת הסניף. בחרו בו כשצוות הסניף צריך להחזיק בסנכרון שלו ולשים לב לכשלים שלו.

חשבון השירות של SQL Server Agent בצד המנוי זקוק לגישת קריאה למסד נתוני ההפצה ולשיתוף תמונת המצב. החשבון הזה הוא הזהות שמופיעה בשגיאות שכפול, וחשבון שירות מקומי בלי הרשאות תחום נכשל בנקודה שנראית כתקלת רשת אבל היא למעשה תקלת הרשאות. בדקו את החשבון לפני שאתם מאתרים תקלות במנהרה. תיקון הכניסה הוא בדרך כלל מהיר יותר מהוכחת החפות של הרשת.

הבעלות הולכת אחרי הסוכן. בחרו push כשהצוות המרכזי צריך להחזיק גם בתזמון וגם בכשלים. מה שתבחרו, כתבו אותו ליד המינוי כדי שהמהנדס הבא ידע היכן להסתכל קודם.

פרסום מחדש משנה את ההתפשטות, לא את הבעלות

אפשר להגדיר מנוי לפרסם מחדש למנויים נוספים, וכך מסד נתונים אחד של סניף יכול לשרת כמה צרכנים מקומיים בלי שכל אחד מהם ימשוך דרך ה-WAN. מסד הנתונים האמצעי מחזיק כעת פרסום וסוכנים משלו. הוא גם יורש הרשאות, ניטור ותוכנית התאוששות שלא היו לו קודם. התפקיד הנוסף הזה הוא המחיר של הסרת מסירת WAN חוזרת.

הסדר המתועד חשוב: אתחלו את המינוי הנכנס לפני יצירת הפרסום במורד. התייחסו לזה כאל שלב במחזור החיים עם אימות, ולא כאל ניירת שמדלגים עליה. היפוך הסדר יוצר שרשרת שנראית מוגדרת ולא מספקת דבר.

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

הוכיחו את המיקום מקצה לקצה

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

USE distribution;
SELECT publication, subscriber_db, subscription_type
FROM dbo.MSsubscriptions;
EXEC sp_replmonitorsubscriptionpendingcmds
  @publisher = 'PUB1', @publisher_db = 'Sales',
  @publication = 'SalesPub', @subscriber = 'BR1',
  @subscriber_db = 'Sales';

ערך subscription_type של 0 הוא push ו-1 הוא pull, ואי אפשר לשנותו במקום, ולכן אי-התאמה פירושה יצירת המינוי מחדש ולא עריכתו. קריאת הפקודות הממתינות אומרת לכם אם הסוכן שנבחר מזיז עבודה או רק פועל. מינוי שמדווח אפס פקודות ממתינות בזמן שטבלת המנוי נשארת ריקה הוא תקלה אחרת מזו שמדווחת על צבר גדל, ושתיהן מובילות לבעלים שונים.

סיימו בשינוי אמיתי: הוסיפו או עדכנו שורה אחת ב-Publisher, המתינו לדיווח של הסוכן וקראו את השורה הזו ב-Subscriber. עשו זאת פעם נוספת דרך הפסקה קצרה ב-VPN כדי לראות כיצד הסוכן מתאושש. מינוי ששורד את המבחן הזה יש לו מיקום שתוכלו לתעד ולהגן עליו.