Комментарии (6)

По Стивен Ллойд Уоткин , четверг 7 января 2010 10:50 вечера

В продолжение на мой последний пост про Zend_Navigation, направлять запросы для sitemap.xml обычаю контроллер / действие , этот пост о dymnamically добавления страницы в контейнер Zend_Navigation во время выполнения / выполнение сценариев.

Его все хорошо указанием страниц в INI или XML- файл, но в какой-то момент вам придется изменения страниц на своем сайте, что вы хотите как часть меню, карта сайта, или должны быть включены в ваш пройденного пути. Поэтому то, что нам нужно сделать, это добавить страниц в наш Zend_Navigation контейнер во время выполнения. Примеры для этого было бы в добавление новостей, блогов или страниц комментариев, и т.д.

Продолжить чтение "динамически добавлять страницы в контейнер Zend_Navigation во время выполнения" »

Комментарии (4)

По Стивен Ллойд Уоткин , в среду 6 января 2010 12:13 утра

Для прямых запросов к / sitemap.xml для пользовательского контроллера и действия в Zend Framework приложения просто добавить в ваш application.ini или альтернативных конфигурационного файла (например, я использую navigation.ini):

 resources.router.routes.sitemap.route = "sitemap.xml"
 Индекс resources.router.routes.sitemap.defaults.controller =
 Карта сайта resources.router.routes.sitemap.defaults.action =

Пример кода для вывода видно, создав действий в соответствующий контроллер (например, моя карта лежит в индекс контроллер, карта действия):

 < PHP
 Класс IndexController
     расширяет Zend_Controller_Action
 {
     / **
      * Оказывает Sitemap на основе Zend_Navigation установки
      * /
     общественного sitemapAction функции ()
     {
    	 Эхо $ этом-> Открыть-> Навигация () -> Карта сайта ();
    	 $ Этом-> Вид-> макета () -> disableLayout ();
    	 $ Этом-> _helper-> ViewRenderer-> setNoRender (TRUE);
     }
 }

Sitemaps может быстро и легко создан с помощью Zend_Navigation , большой краткое руководство (и вообще очень полезно для Zend учебники Framework) является Zend Слепки - Динамическое создание меню сайта и сухарях .

Комментарии (4)

По Стивен Ллойд Уоткин , пятница 1 января 2010 10:40 вечера

Я создал В ответ на эту должность, которая требует меньше конфигурации, см. Модуль на базе макета - Zend Framework .

При использовании Zend Framework с модулями, ее Очевидно, что если вы работаете в различных (суб-) сайтов с одного приложения не обязательно хотят же сценарии макет для каждой части. Я решил пойти со следующей структурой сайта:

  / Применение
     / Контроллеры
         ...
     / Модели
     / Модулей
         / По умолчанию
             / Контроллеры
             / Расположение
                 / Сценарии
             / Просмотров
                 / Сценарии
         / AnotherModule
             ...
     / Сценарии

Проблема заключалась в создании макета сценариев на каждого модуля основе. Ответ пришел через использование помощник действия. Настройка раскладки на каждого модуля основе состоит из трех этапов:

1. Application.ini (или аналогичные установки конфигурации):
   

     admin.resources.layout.layoutPath = APPLICATION_PATH "/ модули / Admin / макеты / сценарии"
    default.resources.layout.layoutPath = APPLICATION_PATH "/ модули / по умолчанию / макеты / сценарии"
    member.resources.layout.layoutPath = APPLICATION_PATH "/ модули / членов / макеты / сценарии"
    affiliate.resources.layout.layoutPath = APPLICATION_PATH "/ модули / филиал / макеты / сценарии" 

2. Создайте свой помощник действия:
   

     <? PHP
    / **
     * Установка макета путь на каждого модуля основе
     *
     * @ Автор Ллойд Уоткин <lloyd@evilprofessor.co.uk>
     * @ С 2010-01-01
     * /
    Класс Pro_Controller_Action_Helper_SetLayoutPath
        расширяет Zend_Controller_Action_Helper_Abstract
    {
        / **
         * Установка макета путь, основанный на модуле
         * /
        общественного preDispatch функции ()
        {
       	 $ = $ Модуль этого-> GetRequest () -> getModuleName ();
   
   	     если ($ = $ загрузки этого-> getActionController ()
   	                        -> GetInvokeArg ("загрузки")) {
   
   	         $ = $ Конфигурации загрузки-> getOptions ();
   
   	         если (isset ($ CONFIG ['макет'] [$ модуль] ['ресурсов'] ['layoutPath'])) {
   	             $ LayoutPath =
   	                  $ CONFIG [$ модуль] ['макет'] ['ресурсов'] ['layoutPath'];
   	             $ Этом-> getActionController ()
   	                  -> GetHelper ("макет")
   	                  -> SetLayoutPath ($ layoutPath);
   	         }
       	 }
        }
    } 

3. И, наконец boostrap помощник действия:
   

     ...
        / **
         * Создает макет сценариев на каждого модуля основе
         * /
        охраняемых _initLayoutHelper функции ()
   	 {
   	     $ Этом-> загрузки ('FrontController');
   	     $ Макета = Zend_Controller_Action_HelperBroker:: addHelper (
   	         новые Pro_Controller_Action_Helper_SetLayoutPath ());
   	 }
    ... 

Комментарии (5)

По Стивен Ллойд Уоткин , в среду 30 декабря 2009 6:30 вечера

Я боролся с создания схемы базы данных для новых Zend Framework проекта. Я использованием пытаются использовать доктрину ORM для моей модели базы данных. Мне нужно, чтобы создать схему так, чтобы он позволил мне установить дату и время по умолчанию для `` DateTime столбца, например, при добавлении нового сообщения я получаю текущего времени. После долгих поисков и экспериментов я нашел решение, поэтому я делю его.

В вашей схеме YAML файл просто сделать следующее:

 Сообщение:
   actAs:
     Timestampable:
       Создано:
         Название: created_at
         Тип: метка
         Формат: YMD H: я: S
       Обновлено:
         Название: last_updated
         Тип: метка
         Формат: YMD H: я: S
   столбцами:
     ID:
       тип: целое число
       первичный: истинный
       автоинкремент: истинный
     Название: строка (255)
     Электронная почта: строка (300)
     сообщение: строка (2000)

Если, с другой стороны, вы не хотите `` updated_at колонке вы можете использовать следующие:

 Сообщение:
   actAs:
     Timestampable:
       Создано:
         Название: created_at
         Тип: метка
         Формат: YMD H: я: S
       Обновлено:
         инвалидов: истинный
   столбцами:
     ID:
       тип: целое число
       первичный: истинный
       автоинкремент: истинный
     Название: строка (255)
     Электронная почта: строка (300)
     сообщение: строка (2000)

Комментарии (3)

По Стивен Ллойд Уоткин , во вторник 29 декабря 2009 10:02 вечера

Я читал Head First Design Patterns недавно и решили написать несколько моделей в качестве примеров PHP для моего собственного блага. Первое, что я решил код на это наблюдатель " . Формальное определение шаблона наблюдателя является:

Наблюдатель картины (подмножество асинхронных публикация / подписка картины ) является программным обеспечением шаблон дизайна , в котором объект , называется предмет, поддерживает список своих иждивенцев, называемых наблюдателей, и уведомляет их автоматически любых изменений состояния, как правило, по телефону один из их методов . Он в основном используется для реализации распределенных систем обработки событий.

Поскольку системы становятся более слабо связанные убедившись, что, когда событие происходит все системы, которые требуют знания эти обновления в сообщении. Например, в блоге, после сохранения должности мы, возможно, потребуется обновление поисковой системы (например Lucene), обновленная карта сайта, теги, электронной почты подписка пользователей и т.д. наблюдателя шаблон позволяет разработчикам добавлять дополнительные слушателей без редактирования их наблюдаемого объекта . Вводя наблюдателей (т.е. обновление поисковой наблюдателя, Sitemap Generator, и т.д.) в теме (т.е. системы после редактирования блог) мы можем позволить ей выполнять все необходимые обновления без каких-либо изменений.

Продолжить чтение 'PHP Design Patterns - наблюдатель Pattern' »

Комментарии (2)

По Стивен Ллойд Уоткин , в пятницу 4 декабря 2009 11:59 вечера

Введение

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

В части 3 мы создали виртуальную машину обработки и настроить Windows машины, чтобы стать времени простоя работников.

Запуск последней версии кода

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

Есть несколько очень простых способов легко мы могли бы сделать это, трюк, однако, заключается в сокращении вычислительной мощности и сетевой трафик в достижении этой цели. Давайте начнем с самого простого решения и улучшить ее медленно пара итераций.

Первый метод будет просто связаться с нашим сервером управления заданиями (через Samba, FTP, или подобный) и потяните вниз последней версии кода. Не очень эффективен, но он будет делать эту работу. Позволяет улучшить, что несколько, как о создании Rsync скрипт и использование, что каждый раз вместо этого? Кроме то, что о вводе наших последних обработки сценария в подрывной проверить код изначально, а затем просто обновление нашего кода при каждом запуске ( SVN обновление )?

В конце мы могли бы в конечном итоге с Баш скрипт (названный хрон каждые 10 минут), который выглядит так просто, как это:

  #! / BIN / Ш.
 PS если топор | Grep-V GREP | GREP PHP > / Dev / нуль
 то
     Эхо "Работа в настоящее время обработки, с выходом"
 еще
     Эхо "Работа не работает, начните прямо сейчас"
     CD / путь / к / рабочей / копии
     SVN обновление
     PHP yourJobProcessingScript.php
 Fi 

Теперь мы можем быть уверены, что с каждого запуска мы определенно установлена ​​последняя кода. Мы обеспечение этого путем обновления нашей базы кода каждый раз, когда мы выполняем запуска и снижения сетевого трафика только передача файлов различия между нашей сети.

В моей демонстрации установки, я сделал именно так, как выше. Subversion была установлена ​​на моем сервере обработки работа, и я просто вытащил последний код из филиала "рабочий", используя "SVN Update". Я также добавил теги номер версии на мой обработки скрипта, который был возвращен в базе данных как часть возвращать результаты. Таким образом, я видел, что мой код обновляется каждый раз, когда я скопировал мое туловище в т. работник филиала, что я определенно установлена ​​последняя обработка сценария.

Используя последние данные

Если ваша работа обработки делает использование данных источников, то в какой-то момент эти будут обновлены. Если вы называете источников данных на основе очень редко вы собираетесь наводнения сети с трафиком, как только ваши работники начнут исполняться чего все в тупик. Для моего решения я решил, что я бы хотел перевести мои источники данных вокруг с моей виртуальных машин.

Держите вы кони там! Что делать, если мои источники данных огромные? Ну это действительно пример того, как много данных идет речь? Это может быть более экономически эффективным, чтобы установить дополнительный жесткий диск большего в каждой машине, чем на покупку дополнительного сервера обработки. Это вопрос о бюджете, и до бизнеса, чтобы решить. Это может быть, что ваши источники данных настолько велик, что его просто невозможным держать, что объем данных в вашей машины работника. В таком случае, что бы вы сделали? Ну, мы могли смотреть на вызове локальный сервер данных, но это может вызвать проблемы с сетью. В этом случае сетка системы, так как это может стать нереальным включить в вашем офисе. Он также может быть то, что вы можете посмотреть в альтернативных стратегий работает, например, только позвонив работников между 8 вечера и 6 утра каждую ночь, и / или регулирования источника запрашивает данные.

Переходя позволяет сказать, что наши источники данных составляет 100 ГБ данных. Ну да это совсем немного данных для перемещения по сети на обновление. Как бы мы гарантируем, что мы последнюю копию данных в этом случае? Rsync возможность, но лично я думаю, запустив ваш последний источник данных на сервере системы обработки заказа и настройки этой операции как мастер репликации (с приятным долгим журнала бен) может быть путь:

При установке каждого из ваших работников в качестве рабов для работы обновления серверного элемента управления к источникам данных будет сочиться вниз красиво, чтобы ваши работники без огромного увеличения сетевой активности (то есть, если вы выполняете огромную обновления данных, и все ваши рабочие удар в сразу). Это имеет преимущества по сравнению с Rsync в том, что вы не получите долгая пауза перед каждой работе; как обновления базы данных, MySQL демона на вашем рабочем будет постоянно обновлять свои данные, а обработка продолжается.

Это, как мне настроить сервер демонстрации. Чтобы настроить репликацию я последовал руководство по MySQL сайта ( Настройка репликации ) и в течение 20 минут у меня была Начальное работника тиражирование управления работой серверов данных. За каждый дополнительный рабочий настройки репликации и процесс работал каждый раз, когда В. М. был скопирован.

Резюме

В этом разделе статьи мы рассмотрели, как легко и безболезненно это сохранить ваш код обработки до настоящего времени using Rsync или subverion (SVN), чтобы сделать работу и уменьшить сетевой трафик в то же time. Мы также обсудили, как сохранить ваши данные в источнике информации до современных, позволяя его просачивания для каждого из ваших работников. Таким образом, мы области обеспечения того, чтобы мы не отставать от бизнес-логики и информации в нашей системе сетки офиса. Там, очевидно, будет бесчисленные альтернативы выполнения этих задач, но здесь были два простых примера, чтобы показать, как легко решение прибыть.

Следующий раз

В заключительной части этой серии, метко назвал Часть 5 , мы будем обсуждать развертывание этой системы. Я буду суммировать то, что было изучено и что мне удалось создать.

Комментарии (3)

По Стивен Ллойд Уоткин , в пятницу 4 декабря 2009 11:37 вечера

Введение

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

В части 2 мы рассмотрели работу сервер будет работать, как и рабочие места должны быть настроены для достижения наибольшее количество обработки в то время, чтобы каждая работа обрабатывается в обязательном порядке.

Настройка рабочего - или LIMP сервера

Следующим шагом в процессе является создание виртуальной работников. Для этого я собираюсь использовать установки CentOS использованием VirtualBox. Я собираюсь установить MySQL и PHP на сервере, также известный как LIMP (Li NUX, м ySQL, P HP) Сервера (я, возможно, сделали это имя вверх).

• Установить VirtualBox на ваши окна машины (по ссылке)
• Загрузка и установка CentOS (текущая версия 5,3) в рамках созданной виртуальной машины

Там нет смысла мне будет это там, наверное, 1000 'с большой учебники там (ну ладно, вот один: Создание и Managing CentOS виртуальной машине под VirtualBox ). Важно отметить, я думаю, что я назвал мою виртуальную GridMachine машины.

Что касается моего выбора виртуализации клиентов и операционной системы, туда не такое уж большое веских причин для каждого варианта. VirtualBox является то, что я использую на моем домашнем компьютере и при поддержке трех основных операционных систем. Я выбрал CentOS как его хороший стабильный OS и я использую его на свой веб-сервер. Я очень верю в правильные инструменты для работы (хотя я подаю заявление "Использовать быстрый и простой для вас" менталитет здесь), поэтому, если операционная система X работает ваш код быстрее и более эффективно использовать его:)

Важно убедиться, что ваш VM используется DHCP, в противном случае для каждой новой виртуальной машины должны быть настроены отдельно, то, что мы не want.By использованием DHCP мы не должны настроить сетевые настройки индивидуально для рабочего машин, DHCP будет стороны из IP-адресов для вас. Поэтому вы можете скопировать вашу виртуальную машину около офиса, не беспокоясь об установке каждого вверх (это улучшает масштабируемость и снижает работник администрации).

Процесс, который вы должны стремиться к достижению бы получить новые физические машины, установки VirtualBox, и то в значительной степени развернуть виртуальные изображения без многое другое. Это может быть мудрым, чтобы настроить все ваши работники в другой подсети, чтобы можно было по крайней мере узнать, сколько машин работает. Вам также необходимо настроить машины на долгосрочную аренду или неограниченное аренды DHCP.

Как для выполнения заданий на работника

Это интересное направление и Есть несколько научно обоснованных методов для обработки заданий на работника. Здесь я просто обсудить два наиболее очевидных:

• Постоянно работает сценария: сценарий, будь то скрипт, или скрипт выполняется один раз на работника и работает как часть бесконечного цикла. Я этот метод дисконтированных как один крах сценария и, возможно, ваши работники перестанут работать без какого-то вмешательства.
• Cron основан выполнения сценария: каждые х минут демон cron стартует звонок на ваш сценарий наладить дело. Без какой-либо проверки это может привести к многим многие копии рабочий скрипт работает.

Мое решение было пойти с хрон который стартует скрипт каждые 10 minutes. мой скрипт выполняет следующие задачи:

1. Получить список процессов и GREP это для "PHP". Если не найден, то продолжить.
2. Call работу кода, в моем случае это будет что-то PHP основанных
3. Работник скрипт завершает свой бег
4. Готовы идти снова на следующий соответствующий вызов

Мой Баш скрипт выглядит примерно следующим:

  #! / BIN / Ш.
 PS если топор | Grep-V GREP |> GREP PHP / Dev / нуль
 то
     Эхо "Работа в настоящее время обработки, с выходом"
 еще
     Эхо "Работа не работает, начните прямо сейчас"
     PHP yourJobProcessingScript.php
 Fi 

Примечание: эхо почти полностью бессмысленно, но может помочь следующий человек, который приходит вместе, чтобы попытаться изменить их.

На этом настройка работника виртуальной машины, быстро, просто и легко копировать в каждой новой части оборудования, которое получил. 'Ум' сетки система действительно не в визуализируется ОС, ее все делать с код, созданный в процессе работы, работы конфигурации, и в том, чтобы задание выполняется в случае необходимости (например, когда хозяин находится в режиме ожидания ).

Настройка Windows для инициализации рабочих

Первой задачей является разработка команды, необходимые для запуска виртуальной машины из командной строки Windows. Если у Вас установлена ​​VirtualBox в папку по умолчанию, и вы назвали ваш работник GridMachine то команда требует, чтобы загрузить ваш работник:

  "C: \ Program Files \ Sun \ VirtualBox \ VBoxManage.exe" startvm GridMachine 

Однако, чтобы запустить сценарий в "обезглавленный" государство нам нужно использовать:

  "C: \ Program Files \ Sun \ VirtualBox \ VBoxHeadless.exe"-startvm GridMachine - VRDP = OFF 

Это приведет к запуску виртуальной машины без графического интерфейса и позволяет ему сохранить состояние изящно. Второй аргумент выключается RDP поэтому он не конфликтует с Windows RDP, или дать вам сообщение о прослушивает порт 3389. Имя виртуальной машины с учетом регистра!

Далее, мы должны установить Windows до стартует наш рабочий В. М. раз машина была простой. Для этого (на Windows XP) вам необходимо перейти Пуск -> Все программы -> Стандартные -> Служебные -> Назначенные задания ", как показано ниже:

Потом нажмите на "Добавить задание ', а затем перейдите к добавлять пользовательские программы. Перейдите на сценарий VBoxManage и нажмите кнопку ОК. Расписание ваша задача для любого из вариантов (мы изменим это в минуту) и продолжить. После пропуска следующего окна окно попросит вас, кто вы хотите, чтобы выполнить эту задачу, я предлагаю либо "Администратор" или создания новых привилегированных пользователей. Помните, что мы не хотим вмешиваться в стандартной учетной сотрудников на машине в любой момент. Нажмите кнопку Далее и установите флажок Показывать дополнительные опции для этой задачи.

К концу выполнения TextBox добавить 'startvm GridMachine' строка нашего и обеспечения того, чтобы работать только тогда, когда вошли в систему остается данную опцию. Посетите Расписание задания следующего и изменить график опуститься до опцию 'в режиме ожидания, выберите количество времени, вы хотели машина, бездействовать, перед тем как перейти к следующей закладке.

Наконец снимите опцию в котором говорится, остановить задачу, если она работает уже X количество времени, но галочку, чтобы отказаться от задачи, если машина не простаивает.

Вот и все, то для установки принимающей окна!

Резюме

В этой части мы создали виртуальную машину в качестве работника, а также способ, в котором мы называем и выполнить наши сценарии обработки заданий (для себя сценарий PHP). Здесь мы рассмотрим, как настроить наши копии Windows для запуска виртуальной машины в режиме обезглавленный, когда компьютер бездействует, и сохранить свое состояние, когда пользователь возобновляет использование машины. Надеюсь, в этот момент вы видите, как это просто для создания такой системы и чешутся, чтобы получить некоторые эксперименты собираетесь сами!

Следующий раз

В части 4 мы будем смотреть на использовании инструментов для обеспечения того, чтобы вы работаете в последней версии кода и данных источников, с тем, что полученные результаты всегда в ногу со актуальный с последними бизнес-информации и логике.

Комментарии (1)

По Стивен Ллойд Уоткин , в пятницу 4 декабря 2009 11:23 вечера

Введение

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

Как PHP разработчик я собираюсь использовать инструменты, которые я использую каждый день, а именно, Linux, MySQL , PHP, VirtualBox и Subversion (SVN). Однако я надеюсь, что это руководство будет адаптироваться к другим языкам и технологиям так же хорошо.

Решение, которое я обеспечивают будет очень слабо в зависимости от типа обработки, мы должны были бы достичь однако это не может быть правдой через всю статью, как я изменю вещи для простоты, или для получения более интересных сценариев использования.

Эти виртуализованных средах будет работать на Windows-машин, так как это то, что большинство отделений перспективе. Обработки, что служба машины не должны мешать сотрудникам использовать эти машины, должны не требуют технического обслуживания в машину, и быть легко устанавливается на новых машинах, как они станут доступны. Кроме того, новые виртуальные машины не требуют дополнительной настройки, поскольку это значительно снижает масштабируемость и простота, при котором сетка система может быть расширена.

Почему Развертывание Grid Управление вычислительным?

Во-первых вы можете подумать, почему бы не использовать вычислительные ресурсы облака, таких как платформы EC2 Амазонки ? Ну причин может быть несколько, например:

• Вы не будете поручить некоторым данным в среде облачных вычислений
• Вы не можете поместить определенные данные в среде облачных вычислений по юридическим причинам (например, данные из страны), потенциально по юридическим причинам, например, NHS записей.
• Вы хотите сохранить свои процессоры близки и иметь полный контроль над аппаратным слишком
• У вас нет средств проекта для запуска облака случаях
• Ваш офис не имеет подключение к Интернету, и поэтому ее нельзя использовать облако ресурсов
• Вам не нравится дождь, облака предложить дождь, поэтому вы держите подальше

Я уверен, что список можно продолжить, но я думаю, что это достаточно.

Преимущества Grid Computing Office

Ну, позволяет сделать некоторые математики (а в истинном стиле физики позволяет сделать некоторые радикальные предположения). Представьте, у вас есть большой мясистый сервер обработки работает 100 рабочих мест в день. В офисе у вас есть 50 машин, которые простаивают по 16 часов в день, каждая из этих машин составляет 10%, как мощный как ваш крепкий обработки сервер. (Все результаты здесь округляются до недооценивать увеличения производительности).

Так, 1 машина * 10% мощности * 2 / 3 времени = 0,067 т. е. 1 рабочий стол обработки в простой процесс может 6 полный рабочий день.

Если вы сейчас масштабы этого до него занимает 15 простоя настольных компьютеров для обработки как много рабочих мест в день в качестве основного сервера обработки делает.

Так в нашем офисе претендует 50 машин мы могли увеличить наши вычислительные мощности от 1 сервер до 4 полных серверов обработки, или мы могли бы быть обработки 400 рабочих мест в день вместо 100.

Обратите внимание, для каких-либо инвестиций в новое оборудование Ваша компания только что увеличила свой ​​пакет перерабатывающих мощностей в 4 раза! Потенциально вы собираетесь увеличить потребление энергии, но от большинства офисе я был в машинах, как правило, остается на ночь в любом случае, чтобы вы могли видеть это как зеленый инициативы.

Другие преимущества также означает, что инвестиции в новый (или обновленный) обработки серверов может быть отложено, если ваши машины офиса являются достаточными, и что вам улучшить мощность вашей машины офиса вашего офиса сетки становится более мощным автоматически.

Технологии

Что вам нужно? (Или, вернее, что же я использую):

• Idle офисной техники (в моем случае ноутбук запасных старой Windows XP)
• VirtualBox (или другого программного обеспечения виртуализации клиентов)
• Виртуальная машина с PHP, MySQL running работает сократить OS, я звоню эти мои LIMP серверов:)
• Вакансии для запуска
• Работа сервера (может быть другой виртуальной машине где-то)

Типичные Вакансии

Типы рабочих мест, что эта система предназначена для работы заключается в следующем:

• Система получает список данных, на которых мы должны соизмерять и возвращать результаты
• Включает проверку соответствия / поиск нескольких (довольно статический) источников данных
• Результаты из источников данных могут потребовать дальнейшей проверки, сливаясь, проверка дополнительных источников данных в ответ на результаты
• Данные возвращается с соответствующими записями, полностью проверены и обработаны
• Каждая запись в работу не зависит от остальных

Поэтому в основном мы смотрим на запущенных заданий, которые требуют смесь поиска в базе данных и некоторого числа хруст, довольно типичный сценарий в бизнес-среде.

Grid решения не только выгодно для обработки заданий этого типа. В принципе, любой процесс, который может быть разделена на независимые единицы могут работать параллельно. Смотрите эту Википедии примеры и более подробную информацию: Grid Computing , но пара известных примеров SETI @ Home и BIONC . Есть рамки для выполнения вычислительных сетей, и это также заслуживает изучения.

Что мы достигли?

К концу этих статей я надеюсь показать, что развертывание Office сетки не нужно быть очень дорогим или времени. Я собираюсь обсудить следующие вопросы:

• Настройка системы управления заданиями, конфигурации задания
• Создание соответствующей обработки виртуальной машины
• Как настроить систему на машину Windows
• Обеспечение вы используете последнюю версию кода и данных
• Развертывания и тестирования
• Заглядывая в будущее

Я буду здания (ОК я построил, то написал это) пример приложения для тестирования концепций на локальном компьютере с Windows XP и виртуальная машина моя "GridMachine. Моя работа серверный элемент управления будет моя главная машина, которая работает Fedora 11 .

Это никоим образом не продемонстрировать полностью рабочий надежные системы, ее означало больше демонстрации и обсуждения показывают, что эти вещи могут быть достигнуты в разумно короткие сроки и при небольших затратах. Пожалуйста, не стесняйтесь, присылайте мне любые комментарии, исправления или улучшения, и я сделаю все возможное, чтобы эта статья обновлена ​​до матча.

Следующий раз

В части 2 я начну, глядя на системы управления работой, и изучить, как рабочие места должны быть настроены для достижения наибольшее количество обработки в то время, чтобы каждая работа обрабатывается в обязательном порядке.

Комментарии (1)

По Стивен Ллойд Уоткин , в пятницу 4 декабря 2009 11:23 вечера

Введение

I work in a company where we run many batch jobs processing millions of records of data each day and I've been thinking recently about all the machines that sit around each and every day doing nothing for several hours. Wouldn't it be good if we could use those machines to bolster the processing power of our systems? In this set of articles I'm going to look at the potential benefits of employing an office grid using virtualised environments.

In Part 1 I gave an overview of the system and technologies I will be using as well as discussed some of the potential reasons why you would want to create an office grid.

Управление заданиями

If you're going to be running jobs then you're going to need some way to manage them. Your job control system (on your job server) needs to be really well thought out before even attempting to run an office grid. So firstly, what are the tasks for a job control system:

• Hand out jobs upon request from workers
• Tell workers what type of jobs to run
• 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.

Работа сервера

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.

Основная настройка

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

As stated previously, the workers will do our job management for us for now, so all we need to really do is find a job that needs processing and get the information. How would we do this? Well pick our job selection criteria and look for jobs, in SQL I did the following:

1. Take any jobs that are not marked as complete but from our worker and reset them (substitute __ME__ with an identifier, easiest would be IP address):

    UPDATE `jobs` SET `status` = 0 WHERE `status` = 1 AND `started_by` = __ME__; 

2. Using our job selection criteria, select a job and tell the control system that this worker is dealing with it:

    UPDATE `jobs` SET `status` = 1, `started_by` = __ME__, `started_at` = NOW() WHERE `status` = 0 OR
   (`status` = 1 AND `started_at` > DATE_SUB(NOW(), INTERVAL X HOUR)) ORDER BY `id` ASC; 

   By grabbing jobs that haven't returned results in X amount of time we ensure that all jobs are run in the event of a worker crashing or going AWOL.

3. Next grab the jobs details followed by the records themselves:

    SELECT * FROM `jobs` WHERE `started_by` = __ME__ LIMIT 1;
   SELECT * FROM `job_records` WHERE `id` = __JOBID__; 

Upon completion of the job we insert our result records and mark the job as complete. Remember as jobs can suspend/resume at any time allow for some robustness in your script. It might be that the task suspends half way through updating the job control system, so checking the number of records in a job and the number of results saved back to the job control system would be a wise move.

In addition, whilst this demonstrates how jobs can be selected and managed from an SQL-query frame you should really be abstracting your job control so that if you decide to switch to using a web service, a file based system, XML , or any other number of systems it will not affect the code above it.

Job Configuration

The next aspect to consider is job size and configuration. By playing with job configuration we can strike an excellent balance between speed, process replication, and reliability. Take a couple of scenarios:

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

In reality there will be no one ideal configuration for your grid setup, much depends on the available resources, types of job, job turnaround time requirements, network capability, and so on. However some guidelines would be:

• Size jobs so that each worker can get through at least 3-4 jobs in a period of 15 hours (the longest likely idle time period)
• Play with the job size so that setup time becomes fairly insignificant compared to the processing time (bearing in mind the above point).
• If a job doesn't complete in double the amount of time (maybe less) you expect it to complete it assume that its gone AWOL and start processing it with another worker. This means you may have to wait up to three times the normal length of a job for it to complete (possibly longer if the subsequent job fails). You may want to reduce this time, but be careful not to reduce it too much as you may start duplicating processing tasks on a regular basis.
• Jobs should be independent of outside requirements as much as possible. The job server, for example, should only be contacted at the start and end of every job.
• Don't saturate your network, this will have two negative effects, your daytime staff will find using the network frustrating and problems may be experienced with connections timing out a problem that will only get worse as you scale your grid.
• Ensure jobs can run on your workers. If jobs become too memory intensive or disk space intensive jobs will start aborting and the only thing you'll notice is a drop in number of jobs processed with no real reason why.

Submitting Results of a Job

When submitting the results of a job it is important to check that results have not been submitted by another worker, especially if the current worker has been dormant for some time.

When results are submitted ensure that the number of results matches the number of records within the job.

As stated previously, and can not be over emphasised, build fault tolerance into job retrieval and results submission. The workers can (and most likely will) go into suspend mode at the most inconvenient of times and this needs to be catered for. Also once again abstracting away your results submission will help cater for future changes to your job control system much easier to deal with.

Резюме

In this section we have looked at what a job control server needs to do and how to get a very basic system set up. We discussed how to retrieve a job from the control system and how best to configure jobs to get the most our of your office grid system. To finish, a paragraph or two on submitting results back to the job control server was presented.

• A job control server manages jobs and ensures that all work units are completed
• By abstracting your job select/results submission we can change the technology of the control server without much problems
• Configure your jobs to ensure that they are run quickly and efficiently without putting too much pressure on your network infrastructure, and without duplicating processing tasks on a regular basis.
• Ensure that you build fault tolerance and error checking into your routines, workers can suspend and resume and the most inconvenient of times. Remember to check if results have already been submitted by another worker.

Следующий раз

In part 3 we'll create our virtual processing machine and set up our windows machines to become idle-time workers.

Комментарии (3)

By Steven Lloyd Watkin , Friday 4th December 2009 11:03 pm

Введение

I work in a company where we run many batch jobs processing millions of records of data each day and I've been thinking recently about all the machines that sit around each and every day doing nothing for several hours. Wouldn't it be good if we could use those machines to bolster the processing power of our systems? In this set of articles I'm going to look at the potential benefits of employing an office grid using virtualised environments.

In Part 4 we looked at using tools to ensure that we're running the latest version of the code and data sources so that obtained results are always up-to-date with the latest business information and logic.

Pre-Deployment

Before deploying your grid system if there's one thing you do and one thing alone it's benchmark your current system ! No matter what you tell colleagues about how much extra work your system is going to do unless you have numbers to back this up your guarantees are nothing. Таким образом,

• how many records can you process currently? Per Day? Per Hour?
• How long does it typically take to turn around a job?
• How much more capacity do you have?

There's also additional questions:

• If your processing server (or one of your processing servers) goes down how will this affect your capabilities, will you be crippled?
• What advantages do you hope/expect to get from a grid system?
• Are your office machines capable of running the jobs?
• Are your (or can you jobs be converted) to wrok in this style of running?

The last major point is to take your time on any major change like this. Update your processing code to work using the new methodology, benchmark again. Possibly set up your processing server to run a virtual machine, after all your processing server will just be another worker (just a very powerful one relatively). Allow the new process to settle.

Развертывания

My suggestion would be to pop into the office one weekend perform all the installations and setup. Do this just before a fortnight's holiday and leave so other poor chap to deal with the consequences… maybe not…

Deployment for a system like this needs to be slow. Despite it being relatively simple to set up this system will affect your entire office infrastructure (well the digital one). Firstly, roll out to a couple of machines at a time, monitor network traffic, how the worker hosts perform on a day-to-day basis. You may need to alter your job configuration in response to your findings.

Once the system has settled with a few machines (lets say 10% of all office machines, ie 5) keep monitoring network traffic and host machine performance. Next benchmark again, you should now be processing 33% more jobs than your first benchmarks. Check this is so, or that you're at least in this ballpark. If not, investigate what is going on before moving on. Repeat this cycle until you happily have all office machines running without killing individual machine performance or grinding your network to a standstill.

At all times keep benchmarking, even after all deployments are made. Check how new code updates affect speed of your system, check all workers are reporting in and processing jobs. Slowly (very slowly) increment your job configuration to get the best from your workers and network.

Стоп!

What if you want to stop your workers from running at some time? They are all out there running, regenerating, and trying their best to process data like hungry insects. The answer may seem obvious but its worth adding just in case its overlooked. Simply edit your processing script with an exit(0) or die() or some other statement to kill your processing job. An important reason why we always try to update to the latest processing script before any run!

Demonstration System

In order to write this set of short articles I created a very small grid to demonstrate the technologies and methodologies. I read lots of articles, tutorials, and used various tools to setup and monitor what was going on. By no means have I gone out and saturated a whole office with traffic and nor have I had access to a regular staff members PC to see how host performance was affected.

My demonstration system was very humble indeed. I used my regular desktop set up as a job control server. On this I had installed mySQL server installed set up as a master in replication, PHP , and SVN linked through apache (for access via worker VM).

I then created a centOS worker machine on VirtualBox on a 6 year old windows XP laptop. I setup scheduled tasks as specified after copying the VM onto the machine and let it go.

The virtual machine was set up with PHP, subversion, and mySQL. I checked out a branch named 'worker' from my job control servers repository and made sure it could be updated using 'svn update'. Next I setup mySQL as a slave and checked that data was replicating from mySQL on the job control server down to the worker VM. After all this I setup the bash script and the cron job.

My processing script basically went along the lines of this (very simple stuff):

• Read in the name field
• Counted the number of similar names in a table from the data source held on the VM
• Counted the number of names as above but splitting the name by spaces (ie forename, middle, surname)
• Repeated this process 1,000 times

Each job took approximately 20 minutes to run. At one point I opened several copies of the worker VM on the windows laptop and watched the jobs be checked off by each of the worker IP addresses. At this point I also confirmed that replication automatically restarted.

Leaving the laptop to idle resulted in a worker starting to process jobs from the job control server. When resuming laptop usage there was a delay of about 30-60 seconds, this is a fair amount of time and staff would need to be made aware that their machine may pause for a short while when returning to the machine. Newer machines may not have a pause of this long. The benefit of the amount of processing performed by these machines during idle periods would more that outweigh staff members having to wait a short period (say 1 minute) on arriving at their machines of a morning (I frequently wait longer that this for a Windows Defender update to take place) provided they were made aware of this (useful time to grab a morning coffee!).

Overall I feel confident that I have demonstrated the technologies that could be used to create such a system. I have shown that such a system does work on a (very) small scale and with some more experimenting could be scaled up utilise the resources of an office's machines. If I don't get to the point of doing this I would be very interested to know/see when someone else does.

Conclusions / Evaluation

The next obvious step would be to actually get a real world example and start to deploy a system such as this within an office environment and see what happens. Asking a business to commit to this without a trail blazing company to prove the technology and effectiveness may be a little difficult. Grid/Distributed computing is very popular is some circles and has some large applications (BIONC, SETI@Home, Folding@Home, etc). I did not, however, find a smaller scale and simple system like this in my searches that could be rolled out within an office environment.

I created a basically free system using mostly open source software and tools available in almost any office. The technologies were basically demonstrated and show to perform and work as expected. Hopefully I have show that with not much work and with a very simple setup you can deploy an office grid computing system that is powerful, cheap, and scalable all at the same time.

Once a system is up and running there is almost no end to the amount of customisation and improvements you can make. For example statistics / benchmarking can easily be added showing the worth of such a system every day. New machines can be added quickly and easily as and when they arrive with upgrades to existing hardware bolstering your processing power.

I hope you've enjoyed reading this series of articles and its given you food for thought on running an office grid system. The solution presented here won't necessarily work in all situations but should be adaptable to allow you to get your data processing done using your own solution.

Please feel free to send me any comments, corrections, or improvements and I'll do my best to keep this article updated to match.