Увядзенне

Я працую ў кампаніі, дзе мы запускаем шмат працоўных месцаў, пакетная апрацоўка мільёны запісаў дадзеных кожны дзень, і я думаў нядаўна пра ўсіх машынах, якія сядзяць кожны дзень нічога не рабіць на працягу некалькіх гадзін. Не было б добра, калі мы маглі б выкарыстоўваць гэтыя машыны для ўмацавання вылічальнай магутнасці нашых сістэм? У гэтай серыі артыкулаў, я буду глядзець на патэнцыйныя выгоды ад выкарыстання офіса сеткі выкарыстанне виртуализированных асяроддзях.

У частцы 1 я даў агляд сістэмы і тэхналогіі, я буду выкарыстоўваць, а таксама абмеркавалі некаторыя з патэнцыйных прычын, чаму вы хацелі б стварыць офіс сеткі.

Кіраванне заданнямі

Калі вы збіраецеся быць запушчаны працоўныя месцы, то вы будзеце мець патрэбу, якім-небудзь чынам кіраваць імі. Ваша задача сістэмы кіравання (на вашу працу сервера) павінен быць вельмі добра прадуманы, перш чым нават спрабаваць запусціць офіс сеткі. Так па-першае, якія задачы для сістэмы кіравання заданнямі:

• Раздайце працоўных месцаў па патрабаванню рабочых
• Скажыце рабочым, які тып запуску заданняў
• Трэк працоўных месцаў
• Пераканайцеся, што працоўныя месцы запускаць толькі адзін раз
• Забяспечыць працу дадзеных работнікаў, ці хаця б сказаць ім, дзе яго атрымаць

Акрамя таго, сістэма павінна быць пашыраецца, які дзейнічае на дадзены момант у рамках аднаго справы можа быць прадоўжаны да запуску некалькіх тыпаў працоўных месцаў, як бізнес бачыць сябе ў сетцы рашэнне. Напрыклад, працоўныя месцы могуць атрымаць прыярытэты, больш чым адзін тып заданні могуць існаваць (гэта значыць некалькі баз код), у выніку вы можаце нават запусціць некалькі розных машын работніка, якія аптымізаваны для кожнага тыпу задання (хоць гэта ніяк адысці ад "агульнага работніка "ідэя). Заўсёды імкніцеся думаць пра будучыню, пры распрацоўцы сістэмы, кароткае бачанне тэрмін можа прывесці да доўгатэрміновай перспектыве расчаравання і павелічэнне часу развіцця.

Праца сервера

Мы збіраемся трэба дзе-то кантраляваць свае працоўныя месцы з, гэта павінна быць адзіная сістэма ў вашай сетцы, якая мае фіксаваную лакатар рэсурсу, будзь то IP-адрас, імя хаста, URL-адрас (з выкарыстаннем ўнутранага DNS) і г.д. Гэта адбываецца таму, што працоўныя павінны ведаць, дзе шукаць працу, работнікам неабходна знайсці сістэму кіравання заданнямі (не сістэма кіравання заданнямі знайсці работнікаў).

Працы самога сервера на самай справе не складаная задача (у базавай сістэме ці інакш), ён павінен захоўваць спіс заданняў, раздаваць працоўныя месцы, атрымліваць вынікі, а затым захоўваць іх для наступнага выкарыстання. Як гэтыя часткі (напрыклад, "раздаваць працоўныя месцы") вызначаюцца можа быць вельмі просты. Пазней мы можам пашырыць сістэмы ўключаюць адміністрацыйны інтэрфейс для дадання, рэдагавання, выдалення, прыпыніць працу, але гэта выходзіць за гэта практыкаванне.

Існуе ніякіх падстаў, тое, што ваша праца сервера не можа быць віртуальная машына працуе на працягу вашага асноўнага сервера апрацоўкі ўмове, што яна не злівае ваду занадта шмат рэсурсаў з яго. Працу сервера аднак мае патрэбу ў высокай даступнасці, калі ён ідзе ўніз, у пятніцу вечарам вы будзеце губляць усе выходныя апрацоўкі, патэнцыйна варта Вам пару тыдняў варта часу апрацоўкі (у параўнанні з вашай асноўнай сервер апрацоўкі ў адзіночку) . Вы можаце хацець разгледзець пытанне аб стварэнні вашай працы сервера з балансавання нагрузкі асяроддзя для забеспячэння высокай даступнасці.

Асноўныя налады

Базавыя наладкі для нашай працы сервера будзе складацца з таго, што я тэлефаную аднаму з маіх LIMP сервераў (гэта значыць Li ММК, м ySql, Р л.з.). Код, які выконваецца на работнікаў Тэа сапраўды будзе працаваць, якія работы ён можа працаваць, узаемадзейнічаючы з працай баз дадзеных сістэмы кіравання. Пазней мы маглі б стварыць вэб-сэрвіс і фактычна раздаваць працоўныя месцы замест таго, рабочыя робяць цяжкую працу самі, але цяпер мы будзем працягваць выкарыстоўваць прынцып KISS (Keep It Simple, Stupid!).

Такім чынам, дазваляе стварыць тры MySQL табліц для вырашэння працоўных месцаў. Гэта будуць працоўныя месцы ``, `jobRecords` і `jobResults`.

Тут я выкарыстоўваю SQL Buddy вялікая невялікая альтэрнатыва PhpMyAdmin толькі таму, што яе лягчэй ўсталяваць на CentOS (для астатніх гл.: 10 Вялікія альтэрнатывы PhpMyAdmin )

Гэтая табліца складаецца з 5 простых палёў,

• ID: Унікальна ідэнтыфікаваць працу
• Назва: Не маглі б быць нумар кліента, або любую колькасць іншых ідэнтыфікатараў
• Статус: Вы павінны ведаць, дзе праца на, напрыклад,
  • 0: Не пачалася
  • 1: Падабраў
  • 2: Завершаны
• started_by: хто пачаў рабіць гэтую працу? Гэта не зусім патрабуецца, але добра было б мець. Я прапаную адсочвання рабочых па іх IP-адрас у сетцы
• started_at: Калі працаўнік пачаць працу? Адсочваючы вакансіі, якія не завершаны на працягу X колькасць часу мы ведаем, што трэба падабраць працу яшчэ раз, і пачала перапрацоўкі іншым работнікам. Рабочыя маглі спыніць апрацоўку / пераходу ў аўтаномны рэжым для любога ліку прычын, збой харчавання, збой, страта сеткі і да т.п.

Лёгка, як гэтая табліца можа быць пашырана за кошт некалькіх дадатковых палёў, каб забяспечыць статыстыку сачэння, калонкі скончыць своечасова, каб убачыць, колькі часу працу ўзяў, лічыльнік каб даведацца, колькі працоўных ўзяў працу (відавочна, гэта павінна, як правіла, 1), прыярытэт заданні, спіс можна працягваць і працягваць. У больш складаных сцэнараў працы можна было б паказаць, колькі памяці работнік будзе мець доступ да (і, такім чынам, варта выкарыстоўваць адпаведныя працоўныя), або нават які тып работніка не спатрэбіцца.

Давайце дадамо некалькі працоўных месцаў прыклад:

Наступная табліца зноў даволі просты для разумення, гэта нашы запісы працу. Яны звязаны з асноўнай табліцы працоўных месцаў да калонцы `jobs_id`. Складнікаў гэтай табліцы вельмі многае залежыць ад дадзеных, якія вы павінны даць, каб вашыя работнікі, дазваляе зрабіць вельмі просты прыклад, калі ў нас ёсць чатыры калонкі:

• ID: ідэнтыфікатар запісу
• імя: Імя ўладальніка
• адрас: адрас Асобы
• jobs_id: ідэнтыфікатар заданні, што гэты запіс звязана з

Трэцяя і апошняя табліца складаецца з табліцы вынікаў, ён гэтак жа, складаюць, як нашы запісу табліцы, а з даданнем некаторых слупкоў можа быць часткай табліцы запісаў:

• job_record_id: Спасылка вынік працы табліцы
• Вынік: дадзеныя выніку

... І гэта ўсё, што трэба для кіравання заданнямі! (Хоць і на самым базавым узроўні) У маім выпадку я паказаў на іншую табліцу, дзе мае дадзеныя на працэсе быў размешчаны, але гэта можа так жа лёгка было файла, параметры для запуску праграмнага кода, то імя яго.

Выбар работы

Як адзначалася раней, працоўныя будуць рабіць сваю працу кіравання для нас цяпер, так што ўсё, што трэба зрабіць, гэта знайсці працу, якая павінна апрацоўкі і атрымання інфармацыі. Як бы мы гэта зрабіць? Ну забраць нашы крытэрыі адбору і працу шукаць працу, у SQL я зрабіў наступнае:

1. Вазьміце любую працу, якая не пазначаныя як поўная, але ад нашага работніка і скінуць іх (замяніць __ME__ з ідэнтыфікатарам, простым будзе IP-адрас):

     UPDATE `працы` SET `статус` = 0 WHERE `статус` = 1 AND `started_by` = __ME__; 

2. Выкарыстоўваючы нашы крытэрыі працы выбару, выберыце працу і сказаць сістэме кіравання, што гэты работнік мае справу з ім:

     UPDATE `працы` SET `статус` = 1, `started_by` = __ME__, `started_at` = NOW () WHERE `статус` = 0 АБО
    (`Статус` = 1 AND `started_at`> DATE_SUB (NOW (), інтэрвал X ЧАС)) ORDER BY `ID` ASC; 

   Па захоп працоўных месцаў, якія не вярнуліся вынікаў у X колькасць часу мы гарантуем, што ўсе работы выконваюцца ў выпадку работніка або збой адбываецца ў самаволку.

3. Наступная захапіць працоўныя месцы дэталі затым самі запісу:

     SELECT * FROM `працу` WHERE `started_by` = __ME__ LIMIT 1;
    SELECT * FROM `job_records` WHERE `ID` = __JOBID__; 

Пасля завяршэння працы мы ўстаўляем нашы запісы выніку і знак працу ў якасці поўнай. Памятаеце, як праца можа прыпыніць / аднавіць у любы момант забяспечыць пэўную ўстойлівасць у ваш сцэнар. Цалкам верагодна, што задача прыпыняе палова шляху праз абнаўленне сістэмы кіравання заданнямі, таму праверка колькасці запісаў у працу, і колькасць вынікаў, захаваны ў сістэме кіравання працай б мудрым крокам.

Акрамя таго, у той час як гэта дэманструе, як працоўныя месцы могуць быць выбраны і кіруюцца з SQL-запыту кадр, які вы павінны быць сапраўды абстрагавання вашай працы кіравання, так што калі вы вырашыце перайсці на выкарыстанне вэб-сэрвісаў, файл сістэмы, заснаванай на XML , або любой іншай лік сістэм, гэта не паўплывае на код вышэй.

Праца канфігурацыі

Наступны аспект, каб разгледзець з'яўляецца памер працоўных месцаў і канфігурацыі. Гуляючы з працы канфігурацыі мы можам забастоўкі выдатны баланс паміж хуткасцю, працэс рэплікацыі, а таксама надзейнасці. Вазьміце пару сцэнарыяў аператара А:

1. Вакансіі прымаць па 1 дзень кожны для запуску: Гэта азначае, што працаўнікам неабходна 15 дзён, каб апрацаваць кожнае заданне (памятаеце, 10% магутнасці для 2/3rds ад часу). Вядома, гэта не мудрая канфігурацыі, ваша праца памер занадта вялікі! Гэта зойме па крайняй меры ўдвая больш часу, каб атрымаць працу павінны апрацоўвацца пачатковай работніка ісці ў самаволку (час, каб забраць, што ён не вярнуў выніку плюс перапрацоўцы часе). У ідэале вы павінны па крайняй меры адзін поўны працоўны лёгка чысціцца ў канцы кожнага перыяду працяглага прастою, такім чынам вы захаваць працоўныя месцы ціканне больш, а ў горшым выпадку праца зойме два дні, каб працэс павінен спачатку пайсці прапаўшымі без вестак.
2. Вакансіі прымаць па 1 хвіліна для запуску: Гэта азначае, што вашы працаўнікі зойме каля 15 хвілін для выканання кожнага задання. Хоць гэта можа спачатку здацца ідэальнай, вы атрымліваеце дадатковую апрацоўку працы падчас абеду, кава-брэйкі, нарад і г.д. дадзены сцэнар ставіць нагрузку на іншыя сферы вашай сістэмы і ўводзіць свае ўласныя праблемы. Напрыклад, па-першае вашы налады / апрацоўкі суадносіны часу будзе ісці прама, таму страты эфектыўнасці сістэмы. Ваша сетка будзе пастаянна струменевае працу інфармацыі розным рабочым хвалюе супрацоўнікаў, якія дон іх паўсядзённым працы. Вы таксама збіраецца надаваць больш нагрузка на сервер апрацоўкі працу, як гэта страва з шмат-шмат маленькіх кавалачкаў працу на рэгулярнай аснове. Нарэшце, у гэтай сітуацыі, калі ваша праца сервер недаступны вы збіраецеся стварыць велізарны зноў увайсці незавершаных работ у той час як больш працоўных месцаў могуць працягу апрацоўкі ў шчасным недасведчанасці, што праца сервера выпрабоўвае цяжкасці.

На самай справе не будзе адна ідэальная канфігурацыя для ўстаноўкі сеткі, шмат што залежыць ад наяўных рэсурсаў, відаў працы, працы час апрацоўкі патрабаванняў, магчымасць працы ў сеткі, і гэтак далей. Аднак некаторыя кіруючыя прынцыпы будуць:

• Памер працоўныя месцы так, каб кожны работнік можа прайсці як мінімум 3-4 працоўных месцаў на працягу 15 гадзін (доўгая верагоднасць прастою перыяд часу)
• Гуляйце з працай памеру, так што час ўстаноўкі становіцца даволі нязначная у параўнанні з апрацоўкай часу (з улікам вышэй кропкі).
• Калі праца не завяршаецца ў два разы больш часу (можа быць менш), вы чакаеце, што для яе завяршэння меркаваць, што яго сышлі ў самаволку і пачаць яе апрацоўку з іншым работнікам. Гэта азначае, што вы, магчыма, прыйдзецца чакаць да трох разоў нармальная даўжыня працу для яго выканання (магчыма, і даўжэй, калі наступная праца не атрымоўваецца). Вы можаце хацець скараціць гэты час, але будзьце асцярожныя, каб не звесці яго занадта шмат, як вы можаце пачаць дубляванне апрацоўкі заданняў на рэгулярнай аснове.
• Вакансіі павінны быць незалежныя ад знешніх патрабаванняў, наколькі гэта магчыма. Працу сервера, напрыклад, павінны быць толькі звязаліся ў пачатку і ў канцы кожнай працы.
• Ці не насыціць вашай сеткі, гэта будзе мець два адмоўных эфектаў, ваш дзённай персанал будзе знайсці з дапамогай сеткі расчараванне і праблемы могуць узнікнуць з падключэннем час чакання праблема, якая будзе толькі пагаршацца, паколькі Вы маштабаваць сетку.
• Забяспечыць працоўныя месцы могуць працаваць на вашых работнікаў. Калі рабочыя месцы становяцца занадта вялікі аб'ём памяці або дыскавай прасторы інтэнсіўнай працы пачнуцца перарываючы і не толькі, што вы заўважыце гэта кропля ў лік працоўных месцаў, апрацоўваюцца ніякай рэальнай прычыны, чаму.

Адпраўка вынікаў працы

Пры падачы вынікі працы, важна пераканацца, што вынікі не былі прадстаўлены на іншага работніка, асабліва, калі бягучы працоўны быў замарожаны на некаторы час.

Калі вынікі прадстаўленага забеспячэння таго, каб колькасць вынікаў супадае з колькасцю запісаў у працу.

Як паказвалася раней, і не можа быць старэйшыя за падкрэсліў, будаваць адмоваўстойлівасць на пошук працы і вынікі прадстаўлення. Работнікі могуць (і хутчэй за ўсё) пераходзяць у рэжым чакання ў самы непадыходны раз, і гэта павінна быць абслужаны. Таксама яшчэ раз абстрагуючыся ад вашых вынікаў прадстаўлення дапаможа задаволіць будучыя змены ў працу сістэмы кіравання значна прасцей мець справу.

Рэзюмэ

У гэтым section мы глядзелі на тое, што сервер кіравання заданнямі, трэба зрабіць і як яго атрымаць вельмі простыя сістэмы, створанай. Мы абмеркавалі, як атрымаць працу з сістэмай кіравання і як лепш наладзіць працоўныя месцы, каб атрымаць большасць нашых вашай сістэмы сеткі офіса. Каб скончыць, адзін-два абзаца аб прадстаўленні вынікаў на сервер кіравання заданнямі была прадстаўлена.

• Сервер кіравання заданнямі кіруе заданнямі і гарантуе, што ўсе працы будуць завершаны адзінак
• Па абстрагаванне ваша праца выбару / вынікі прадстаўлення мы можам змяніць тэхналогію кіравання серверам без асаблівых праблемы
• Налада працоўных месцаў, каб яны выконваюцца хутка і эфектыўна, не падвяргаючы занадта шмат ціску на сеткавую інфраструктуру, і без дублявання задач апрацоўкі на рэгулярнай аснове.
• Пераканайцеся, што вы будуеце адмоваўстойлівасць і памылак checking у вашы працэдуры, працаўнікі могуць прыпыніць і аднавіць, і ў самы непадыходны разоў. Не забудзьцеся праверыць, калі вынікі ўжо былі прадстаўлены іншым работнікам.

Наступны раз

У частцы 3 мы створым нашу віртуальную машыну апрацоўкі і стварылі нашы вокны машыны, каб стаць часу прастою работнікаў.

Адзін адказ на "Офіс Grid Computing выкарыстаннем віртуальных асяроддзяў - Частка 2"

1. Гідролізу кажа:

   Чацвер 18 лютага 2010 г у 7:11 вечара

   Хэя! Добрая канцэпцыя, але, магчыма, гэта сапраўды праца?

   Адказ