הקדמה
אני עובד בחברה שבה אנחנו רצים הרבה עבודות אצווה עיבוד מיליוני רשומות של נתונים בכל יום חשבתי לאחרונה על כל מכונות לשבת כל יום לעשות כלום במשך כמה שעות. זה לא יהיה טוב אם נוכל להשתמש במכונות האלה כדי לחזק את כוח העיבוד של המערכות שלנו? בסדרת מאמרים זו אני הולך להסתכל על היתרונות הפוטנציאליים של העסקת משרד לרשת באמצעות סביבות וירטואליות.
ב חלק 1 נתתי סקירה כללית של מערכת וטכנולוגיות אני יהיה להשתמש גם כפי שנדון כמה סיבות אפשריות למה אתה רוצה ליצור רשת המשרד.
איוב בקרה
אם אתה הולך להיות ריצה עבודות אז אתה הולך צריך קצת דרך לנהל אותם. השליטה תפקידך במערכת (בשרת העבודה שלך) צריכה להיות מחשבה ממש טוב לפני אפילו מנסה להפעיל רשת המשרד. אז קודם כל, מה הן משימות עבור מערכת בקרה עבודה:
- עבודות יד, לבקשת העובדים
- תגיד איזה סוג של עובדים עבודות לרוץ
- עקוב אחר משרות
- ודא כי עבודות לרוץ רק פעם אחת
- לספק נתונים עבודה לעובדים, או לפחות לספר להם איפה להשיג אותו
המערכת גם צריכה להיות להרחבה, פתרון זה עובד עכשיו במקרה אחד ניתן להאריך להריץ מספר סוגים של עבודות כעסק רואה את שווה בפתרון הרשת. לדוגמה, עבודה יכולים לזכות סדרי עדיפויות, יותר מסוג אחד העבודה יכולה להתקיים (כלומר כמה בסיסים קוד), בסופו של דבר אתה יכול אפילו להריץ מספר מכונות עובד השונים מותאמים לכל סוג של עבודה (למרות שעושה להתרחק העובד הגנרי "הרעיון). תמיד מנסה לחשוב על העתיד כאשר בפיתוח מערכות, חזון לטווח קצר יכול להוביל לתסכול ארוך טווח זמן הפיתוח גדל.
איוב שרת
אנחנו צריכים לשלוט במקום עבודות שלנו, זה צריך להיות במערכת רק ברשת שלך, כי יש Resource Locator קבוע, להיות כתובת IP, שם המארח, כתובת האתר (באמצעות DNS פנימי), וכו 'זה בגלל העובדים צריכים לדעת איפה לחפש עבודה, עובדים צריכים למצוא את מערכת בקרת עבודה (לא מערכת בקרת עבודה למצוא את העובדים).
שרת העבודה עצמה לא ממש יש משימה מסובכת (מערכת בסיסית בכל מקרה), זה צריך לאחסן רשימה של מקומות עבודה, לחלק משרות, לקבל תוצאות, ולאחר מכן לאחסן אותם אחזור מאוחר יותר. כמה חלקים אלה ('יד ג'ובים "כגון) מוגדרים יכול להיות מאוד בסיסי. מאוחר יותר אנו יכולים להרחיב את המערכת לכלול ממשק הניהול להוסיף, לערוך, למחוק, להשעות את העבודות, אבל זה מעבר התרגיל הזה.
אין שום סיבה שהיא אז שרת העבודה שלך לא יכול להיות מפעיל וירטואלי בתוך השרת עיבוד הראשי שלך בתנאי זה לא לטמיון משאבים רבים מדי ממנו. שרת העבודה אולם צריך זמינות גבוהה, אם הוא יורד ביום שישי בערב אתה הולך לאבד סוף שבוע שלם של עיבוד, פוטנציאל עולה לך כמה שבועות בשווי של זמן עיבוד (לעומת שרת עיבוד הראשי שלך לבד) . אולי כדאי לשקול לשים שרת העבודה שלך על הסביבה עומס מאוזנת עבור זמינות גבוהה.
יסוד הגדרת
The basic setup for our job server will consist of what I'm calling one of my LiMP servers (that is Li nux, m ySql, P HP). The code running on the workers will actually work out what jobs it can run by interacting with with job control system databases. Later on we could create a web service and actually hand out jobs rather than having the workers do the hard work themselves, but for now we'll continue using the KISS principle (Keep it Simple, Stupid!).
So, lets create three mySQL tables to deal with jobs. These will be `jobs`, `jobRecords`, and `jobResults`.
Here I'm using SQL Buddy a great little alternative to phpMyAdmin just because its easier to install on centOS (for others see: 10 Great alternatives to phpMyAdmin )
This table consists of 5 simple fields,
- id: Uniquely identify the job
- name: Could be a client reference, or any number of other identifiers
- Status: You need to know where the job is at, eg
- 0: Not started
- 1: Picked up
- 2: Completed
- started_by: Who's started doing the job? This isn't entirely required but is a nice to have. I'd suggest tracking workers by their IP address on your network
- started_at: When did the worker start the job? By tracking jobs that have not completed within X amount of time we know we need to pick up the job once again and start processing by another worker. Workers could stop processing/go offline for any number of reasons, power failure, crash, network loss, etc.
It is easy how this table could be extended with a few additional fields to allow for statistics tracking, a finish time column to see how long the job took, a counter to see how many workers picked up the job (obviously this needs to tend to 1), job priority, the list can go on and on. In more complex job scenarios it would be possible to specify how much memory the worker would need access to (and therefore only use suitable workers), or even what type of worker would be required.
Lets add a few example jobs:
The next table again is quite simple to understand, these are our job records. They are linked to the main jobs table by a column `jobs_id`. The make up of this table very much depends on the data that you need to supply to your workers, lets make a very simple example where we have four columns:
- id: ID of the record
- name: Person's name
- address: Person's address
- jobs_id: The job ID that this record is linked to
The third and final table consists of a results table, it has much the same make up as our records table, and with the addition of some columns could be part of the records table:
- job_record_id: Link the result to the job table
- result: The result data
…and that's all you need for job control! (albeit at a very basic level) In my case I'm pointed to another table where my data to process was located, but this could just as easily been a file, parameters to run simulation code, you name it.
Selecting a job
כאמור, העובדים יעשו וניהול העבודה שלנו אצלנו עכשיו, אז כל מה שאנחנו צריכים באמת לעשות הוא למצוא עבודה כי צריך עיבוד לקבל את המידע. איך נעשה את זה? ובכן לבחור בחירה תפקידנו קריטריונים לחפש עבודה, ב-SQL עשיתי את הפעולות הבאות:
- קח את כל המשרות שאינם מסומנים כמו להשלים אלא עובד שלנו לאפס אותם (תחליף __ME__ עם מזהה, הכי קל יהיה כתובת ה-IP):
UPDATE `עבודות` SET `מעמד` = 0 WHERE `מצב` ו `= 1 started_by` = __ME__;
- באמצעות בחירת התפקיד שלנו קריטריונים, בחר עבודה לספר את מערכת הבקרה כי עובד זה להתמודד עם זה:
UPDATE `עבודות` SET `מעמד` = 1 `,` started_by = __ME__, `started_at` = NOW () WHERE `מעמד` = 0 או
(`מצב` ו `= 1 started_at`> DATE_SUB (NOW (), שעה INTERVAL X)) ORDER BY `id` ASC;
על ידי גרירה עבודות לא חזרו תוצאות בסכום X זמן אנו מבטיחים כי כל עבודות מתנהלים במקרה של עובד מתרסק או הנפקדות.
- הבא לתפוס את המשרות פרטים ואחריו את הרשומות עצמם:
SELECT * FROM `עבודות` WHERE `started_by` = __ME__ LIMIT 1;
SELECT * FROM `job_records` WHERE `id` = __JOBID__;
עם סיום העבודה אנו להוסיף רשומות התוצאה שלנו סימן את העבודה כמו שלמה. זכור כמו עבודות יכול להשעות / לחדש בכל עת לאפשר חוסן חלק בתסריט שלך. זה יכול להיות שהמשימה משהה בחצי הדרך דרך לעדכן את מערכת בקרת עבודה, כך בודקים את מספר הרשומות עבודה ואת מספר התוצאות הציל בחזרה למערכת בקרת עבודה יהיה צעד חכם.
בנוסף, בזמן זה מדגים כיצד ניתן לבחור עבודות וניהל ממסגרת-SQL לשאילתת אתה באמת צריך להיות הפשטה מלאה העבודה שלך, כך שאם אתם מחליטים לעבור באמצעות שירות אינטרנט, מערכת קבצים המבוססת על XML , או אחרת מספר מערכות זה לא ישפיע על קוד מעליו.
איוב תצורת
ההיבט הבא הוא לשקול גודל העבודה תצורה. על ידי משחק עם תצורת עבודה שאנחנו יכולים על איזון מצוין בין מהירות, תהליך השכפול, ואמינות. קחו of תרחישים הזוג:
- משרות לקחת 1 כל יום לרוץ: משמעות הדבר היא כי העובדים שלך צריך 15 ימים כל תהליך העבודה (זוכרים 10% מכוח עבור 2/3rds הזמן). זה בבירור לא תצורה חכם, גודל התפקיד שלך הוא גדול מדי! זה היה לוקח לפחות כפול זמן למצוא עבודה מעובד לעובד הראשוני צריך ללכת נפקד (זמן לאסוף כי לא חזר התוצאה בתוספת הזמן reprocessing). בשנת אידיאל היית אחד לפחות משרה מלאה פינה בקלות על ידי תום תקופת המתנה ארוכה מדי, ככה אתה שומר את עבודות מתקתקת שוב על המקרה הגרוע ביותר בעבודה היה לוקח יומיים לתהליך הראשון צריך ללכת חסר.
- משרות לקחת 1 דקה לרוץ: משמעות הדבר היא כי העובדים שלך לקחת בערך 15 דקות לרוץ כל עבודה. בעוד זה עלול בתחילה נראה אידיאלי, אתה מקבל עיבוד עבודה נוספת בזמן ארוחת צהריים, הפסקות קפה, פגישות, וכו 'תרחיש זה מעמיד עומס על אזורים אחרים של המערכת ומציג בעיות משלה. לדוגמה, ראשית יחס ההתקנה / עיבוד שלך הזמן הוא הולך ישר, ולכן מאבדים יעילות המערכת. הרשת שלך תהיה כל הזמן הזרמת מידע עבודה לצוות עובדים שונים מתסכל אשר דונג יום שלהם לעבוד היום. אתה גם הולך לשים יותר מאמץ בשרת שלך עבודה עיבוד כמו זה צריך צלחת החוצה המון המון חתיכות קטנות של עבודה על בסיס קבוע. לבסוף, במצב זה אם שרת העבודה שלך יורד שאתה הולך ליצור יומן בחזרה עצום של עבודה שלא הושלמה ואילו עבודות יכול יותר של המשך עיבוד מאושרים ולא שיערו כי שרת העבודה היתה בקשיים.
במציאות לא יהיה אידיאלי תצורה אחת ההגדרות רשת שלך, הרבה תלוי המשאבים הזמינים, סוגי עבודה, עבודה תפנית דרישות זמן, יכולת הרשת, וכן הלאה. אולם הנחיות כמה יהיה:
- משרות גודל כך כל עובד יכול לעבור לפחות 3-4 מקומות עבודה בתקופה של 15 שעות (זמן רב סביר תקופת המתנה)
- לשחק עם גודל המשימה, כך זמן ההתקנה הופך זניח למדי בהשוואה לתקופה עיבוד (אם נזכור את נקודת לעיל).
- אם עבודה לא להשלים בסכום כפול של זמן (אולי פחות) אתה מצפה להשלים אותה להניח כי נפקד נעלם שלה להתחיל לעבד אותו עם עובד אחר. זה אומר שאתה יכול לחכות עד אורך שלוש פעמים נורמלי של עבודה על זה כדי להשלים (אולי יותר אם העבודה שלאחר מכן נכשל). מומלץ להפחית את הזמן, אבל להיזהר שלא להפחית יותר מדי כמו שאתה יכול להתחיל לשכפל משימות עיבוד על בסיס קבוע.
- משרות אמורה להיות בלתי תלויה בדרישות מחוץ ככל האפשר. שרת העבודה, למשל, צריך רק להיות קשר בתחילת ובסוף כל עבודה.
- אל להרוות את הרשת שלך, זה יהיו שתי השפעות שליליות, צוות היום שלך ימצאו באמצעות הרשת מתסכל ובעיות עשוי להיות מנוסה עם קשרים העיתוי החוצה בעיה רק יחמיר כפי שאתה בהיקף לרשת שלך.
- ודא עבודות יכול לרוץ על העובדים שלך. אם עבודות להיות גם זיכרון עבודות שטח אינטנסיבית או דיסק אינטנסיבי יתחיל להפיל והדבר היחיד תבחין היא ירידה במספר המשרות מעובד עם בלי שום סיבה אמיתית מדוע.
תוצאות הגשת עבודה
בעת הגשת תוצאות של עבודה חשוב לבדוק כי התוצאות לא הוגשו על ידי עובד אחר, במיוחד אם העובד הנוכחי כבר רדום במשך זמן מה.
כאשר תוצאות מוגשים להבטיח את מספר התוצאות תואם את מספר הרשומות בתוך העבודה.
כאמור, ולא ניתן יותר דגש, לבנות עמידות בפני תקלות לתוך אחזור העבודה והגשת תוצאות. העובדים יכולים (וככל הנראה יהיה) להיכנס למצב להשעות בבית נוח ביותר של פעמים, זה צריך להיות מובאים בחשבון. כמו כן שוב הפשטה משם הגשת התוצאות יסייעו לספק עבור שינויים עתידיים למערכת בקרת עבודה הרבה יותר קל להתמודד איתו.
תקציר
ב section זה יש לנו הסתכל מה שרת השליטה עבודה צריך לעשות ואיך להשיג מערכת בסיסית מאוד להגדיר. דיברנו על איך לאחזר עבודה ממערכת מלאה מהי הדרך הטובה ביותר להגדיר את המשרות להפיק את המרב שלנו של המערכת במשרד הרשת. כדי לסיים, פסקה או שתיים על הגשת התוצאות בחזרה לשרת לשלוט העבודה הוצגה.
- שרת מצליח לשלוט עבודה משרות מבטיח כי כל יחידות העבודה הושלמו
- על ידי הפשטה העבודה שלך ובחר / תוצאות הגשת אנחנו יכולים לשנות את הטכנולוגיה של שרת לשלוט ללא בעיות הרבה
- הגדרת עבודות שלך כדי להבטיח שהם מופעלים במהירות וביעילות בלי לשים יותר מדי לחץ על תשתית הרשת שלך, בלי לשכפל עיבוד משימות על בסיס קבוע.
- ודא כי אתה בונה עמידות בפני תקלות ו checking שגיאה לתוך השגרה שלך, העובדים יכולים להשעות ולחדש את נוח ביותר של פעמים. זכור לבדוק אם התוצאות כבר הוגשו על ידי עובד אחר.
בפעם הבאה
ב חלק 3 ניצור מכונה וירטואלית עיבוד שלנו להגדיר מכונות החלונות שלנו להיות פעיל בזמן עובדים.
תגובות (2) 
לפי כל הגדרה של העובדים שלך כעבד הבקרה עבודה עדכונים בשרת למקורות נתונים שלך לטפטף יפה לעובדים שלכם ללא גידול עצום בפעילות הרשת (כלומר, אלא אם לבצע עדכון נתונים ענק כל העובדים שלך בעיטה בבת אחת). זו יתרונות על פני rsync, כי אתה לא תקבל הפסקה ארוכה לפני כל עבודה, כמו עדכוני מסד הנתונים, mysql הדמון על העובד שלך יהיה לעדכן את הנתונים בזמן העיבוד ממשיך. 
