Wprowadzenie
Pracuję w firmie, w której prowadzimy wiele miejsc pracy, przetwarzania wsadowego milionów rekordów danych każdego dnia i myślałam ostatnio o komputerach, które siedzą każdy dzień nic nie robi przez kilka godzin. Czy nie byłoby dobrze, gdybyśmy mogli korzystać z tych maszyn wzmacnia moc naszego systemu? W tym zbiorze artykułów mam zamiar sprawdzić potencjalne korzyści z zatrudniania biura sieci za pomocą środowiskach wirtualnych.
W części 1 dałem przegląd systemu i technologii, których będę używał, jak również omówione niektóre z potencjalnych powodów, dla których chcesz utworzyć sieci biurowych.
Job Control
Jeśli masz zamiar zostać uruchomiony pracy wtedy będziemy potrzebować jakiś sposób nimi zarządzać. System kontroli pracy (na serwerze pracy) musi być naprawdę dobrze przemyślane zanim nawet próby uruchomienia sieci biurowych. Więc po pierwsze, jakie są zadania dla systemu kontroli pracy:
- Rozdaj pracy na wniosek pracowników
- Powiedz pracowników, jaki typ zadań wykonywanych
- Track jobs
- Ensure that jobs are only run once
- Provide job data to workers, or at least tell them where to get it
The system also needs to be extensible, a solution that works for now in a single case may be extended to run several types of jobs as the business sees the worth in a grid solution. For example, jobs may gain priorities, more than one job type may exist (ie several code bases), eventually you may even run several different worker machines that are optimised for each type of job (although that does move away from the 'generic worker' idea). Always try to think about the future when developing systems, a short term vision can lead to longer term frustration and increased development time.
Job Server
We're going to need somewhere to control our jobs from, this should be the only system in your grid that has a fixed resource locator, be that an IP address, host name, URL (using internal DNS), etc. This is because the workers need to know where to look for jobs, workers need to find the job control system (not the job control system find the workers).
The job server itself doesn't really have a complicated task (in a basic system anyhow), it needs to store a list of jobs, hand out jobs, receive results, and subsequently store them for later retrieval. How these parts (such as 'hand out jobs') are defined can be very basic. Later on we can extend the system to include an administration interface to add, edit, delete, suspend jobs but this is beyond this exercise.
There is no reason whatsoever then that your job server could not be a virtual machine running within your main processing server provided it doesn't drain too many resources from it. The job server however does need high availability, if it goes down on a Friday evening you're going to lose a whole weekend of processing, potentially costing you a couple of weeks worth of processing time (when compared to your main processing server alone). You may want to consider putting your job server on a load balanced environment for high availability.
Basic Setup
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
Jak stwierdzono wcześniej, pracowników zrobimy zarządzania zadaniami dla nas teraz, więc wszyscy musimy naprawdę jest znaleźć pracę, która wymaga przetwarzania i uzyskać informacje. Jak to zrobić? Dobrze wybrać nasze kryteria wyboru pracy i szukać pracy w SQL zrobiłem następujące brzmienie:
- Podjęcie jakichkolwiek zadań, które nie są oznaczone jako kompletne, ale z naszych pracowników i ich reset (__ME__ zastąpić identyfikator, najłatwiej byłoby adres IP):
UPDATE `pracy` SET `status` = 0 WHERE `status` = 1 i "started_by` = __ME__;
- Korzystanie z naszych kryteriów wyboru pracy, wyboru pracy i powiedzieć, że ten system kontroli pracownik ma do czynienia z tym:
UPDATE `pracy` SET `status` = 1, "started_by` = __ME__, `started_at` = NOW () WHERE `status` = 0 lub
(`Status` = 1 I `started_at`> DATE_SUB (NOW (), przedział X HOUR)) ORDER BY `id` ASC;
Chwytając miejsc pracy, które nie zwróciło wyników w kwocie X czasu mamy pewność, że wszystkie zadania są uruchamiane w razie awarii lub pracownik będzie AWOL.
- Następnie pobieramy po szczegóły pracy rekordy siebie:
SELECT * FROM `pracy` WHERE `started_by` = __ME__ LIMIT 1;
SELECT * FROM `job_records` WHERE `id` = __JOBID__;
Po zakończeniu pracy możemy wstawić nasze dane i zaznaczyć wynik pracy za kompletną. Pamiętaj, jak praca może zawiesić / wznowić w każdej chwili umożliwić pewną stabilność w skrypcie. Możliwe, że zadanie zawiesza w połowie aktualizacji systemu kontroli pracy, więc sprawdzenie liczby rekordów w pracy i liczbę wyników zapisana w systemie kontroli pracy byłoby mądre posunięcie.
Ponadto, choć ten pokazuje, jak miejsca pracy mogą być wybierane i zarządzane z SQL-ramkę zapytania należy być naprawdę abstrahując od Ciebie pracy tak, że jeśli zdecydujesz się przejść na korzystanie z usług internetowych, system plików, XML , lub inny szereg systemów nie wpłynie kod powyżej.
Konfiguracja pracy
Kolejny aspekt, należy rozważyć, jest wielkości zadania i konfiguracji. Grając w konfiguracji pracy możemy strike doskonałą równowagę między szybkością, procesu replikacji i niezawodności. Weź parę szeĹ> ciu przypadkĂłw scenariuszy:
- Praca trwa od 1 dzień każdego uruchomić: Oznacza to, że pracownicy potrzebują 15 dni na proces każdej pracy (pamiętaj 10% mocy dla 2/3rds czasu). Oczywiście nie jest to mądry konfiguracji, rozmiar pracy jest zbyt duży! Zajmie to co najmniej dwukrotność czasu, aby dostać pracę przetwarzane należy wstępnego pracownik go AWOL (czas, aby podnieść, że nie zwróciło w wyniku przerobu plus czas). W idealnym można mieć co najmniej jeden pełny praca łatwo usuwane przez koniec każdego długi okres bezczynności, w ten sposób można zachować miejsca pracy i ponad dolną, w najgorszym przypadku pracy zajmie dwa dni, aby proces ten powinien najpierw przejść brakuje.
- Praca trwa od 1 minuty do uruchomienia: Oznacza to, że pracownicy biorą około 15 minut do uruchomienia każdej pracy. O ile może początkowo wydawać idealną, można uzyskać dodatkowe przetwarzanie w czasie pracy na lunch, przerwy kawowe, spotkania itp. scenariusz ten obciąża innych obszarów systemu i wprowadza swoje własne problemy. Przykładowo, po pierwsze konfiguracji stosunek czasu przetwarzania zamierza iść w prawo w dół, tracąc tym samym skuteczność systemu. Twoja sieć będzie stale streaming informacji o pracy dla różnych pracowników frustrujące pracowników, którzy są dong ich codziennej pracy. Jesteś także zamiar umieścić więcej obciążenie serwera przetwarzanie zadań, ponieważ musi rozdać wiele, wiele małych kawałków pracy na bieżąco. Wreszcie, w tej sytuacji, jeśli serwer praca idzie w dół masz zamiar stworzyć ogromne zaległości w pracy, podczas gdy większe nieukończonego zadania może dalszego przetwarzania w błogiej nieświadomości, że serwer praca była w trudnej sytuacji.
W rzeczywistości nie będzie nikogo, idealne konfiguracji konfiguracji sieci, wiele zależy od dostępnych środków, rodzaj pracy, wymagane turnaround czasu pracy, możliwość pracy w sieci, i tak dalej. Jednak kilka wskazówek, to:
- Rozmiar pracy tak, że każdy pracownik może przejść przez co najmniej 3-4 nowych miejsc pracy w ciągu 15 godzin (najdłuższy czas bezczynności prawdopodobnie)
- Zagraj z wielkości zadania, tak aby czas instalacji staje się dość nieznaczny w porównaniu do przetwarzania czasu (biorąc pod uwagę punkt powyżej).
- Jeśli zadanie nie zakończy się w podwójnej ilości czasu (może mniej) można się spodziewać jej zakończenie założyć, że tego nie ma AWOL i rozpoczęcie jego przetwarzania go innym pracownikiem. Oznacza to, być może trzeba będzie czekać nawet do trzech razy ich normalnej pracy na jej zakończenie (ewentualnie dłużej, jeśli kolejne zadania nie). Możesz skrócić ten czas, ale należy uważać, aby nie zmniejszyć to zbyt wiele jak można rozpocząć powielania zadań przetwarzania na bieżąco.
- Praca powinna być niezależna poza wymagania jak najwięcej. Serwer pracy, na przykład, skontaktujemy się tylko na początku i na końcu każdego zadania.
- Nie nasycenia sieci, będzie to miało dwa negatywne skutki, Twój dzień znajdzie pracowników za pośrednictwem sieci frustrujące i mogą występować problemy z połączeniami limit czasu problem, że będzie tylko gorzej jak skalowanie sieci.
- Zapewnienie miejsc pracy można uruchomić na swoich pracowników. Jeśli zatrudnienie zbyt dużej pamięci lub miejsca na dysku intensywnej pracy zacznie przerywać i jedyne co można zauważyć, jest spadek liczby miejsc pracy przetwarzane bez rzeczywistego powodu.
Przesyłanie Wyniki pracy
Przy składaniu wyniki pracy ważne jest, aby sprawdzić, czy wyniki nie zostały przedstawione przez innego pracownika, zwłaszcza jeśli obecny pracownik został uśpiony na jakiś czas.
Kiedy wyniki podane zapewnienia, że liczba wyników odpowiada liczbie rekordów w pracy.
Jak stwierdzono wcześniej, i nie można przecenić, budować odporność na uszkodzenia wyszukiwania miejsc pracy i przekazywania wyników. Pracownicy mogą (i najprawdopodobniej) przejść do trybu wstrzymania na najbardziej uciążliwe razy i musi to być coś dla siebie. Także po raz kolejny abstrahując od Twojego zgłoszenia wyników pomoże zaspokoić przyszłe zmiany w systemie kontroli pracy łatwiej sobie poradzić.
Podsumowanie
W tym section patrzyliśmy co serwer kontroli pracy musi to zrobić i jak się bardzo prosty system konfiguracji. Rozmawialiśmy jak odzyskać pracę z systemu kontroli i jak najlepiej skonfigurować zadania, aby jak najlepiej naszym systemu sieci biurowych. Aby zakończyć, ust lub dwóch od złożenia wyniki z powrotem do serwera kontroli pracy został przedstawiony.
- Serwer kontroli pracy zarządza miejsc pracy i zapewnia, że wszystkie jednostki pracy są zakończone
- W abstrakcji pracy select / przekazywania wyników możemy zmienić technologię na serwer kontroli bez większych problemów
- Konfigurowanie pracy w celu zapewnienia, że są one uruchomić szybko i sprawnie bez zbytniego nacisku na infrastrukturę, a nie powielając zadań przetwarzania na bieżąco.
- Upewnij się, że budowanie odporności na uszkodzenia i checking błąd na swoje procedury, pracowników może zawiesić i wznowić i najbardziej uciążliwe razy. Pamiętaj, aby sprawdzić, czy wyniki zostały już przedstawione przez innego pracownika.
Następny raz
W części 3 stworzymy naszej wirtualnej obrabiarki i skonfigurować nasze komputery z Windowsem na bezczynność wymiarze czasu pracy.
Komentarze (2) 
Przez ustawienie każdego z pracowników się jako niewolnik do aktualizacji kontroli pracy serwera do źródeł danych dotarły ładnie do pracowników bez ogromny wzrost aktywności sieciowej (to jest chyba wykonać duże uaktualnienie danych i wszystkich pracowników w kick na raz). Ten ma przewagę nad rsync tym, że nie dostanie długa przerwa przed każdą pracę, jak aktualizacje bazy danych, mysql demona na pracownika będzie stale aktualizować swoje dane a przetwarzanie jest kontynuowane. 
Artykuły , Computing , Computing Grid , Linux , PHP , Programowanie WWW | 
bash , partii , kod , bazy danych , sieci , Linux , master , mySQL , PHP , przetwarzania , redbean , replikacji , rsync , skrypt , slave , subversion , svn , svn update 
