Дата-центр для малого предприятия

 АЛЕКСАНДР ТЕТЮШЕВ, к.т.н., доцент кафедры АВТ, Вологодского Государственного Технического Университета (ВоГТУ)

Дата-центр для малого предприятия

Идея создания SaaS (Server as a Service) для небольшого предприятия появилась у меня давно. Расскажу, как использование информационных технологий позволяет создавать ключевые преимущества в бизнесе даже для небольших фирм

Основное отличие предприятия малого бизнеса от среднего и крупного – хроническое отсутствие денег, тем более на создание и содержание ИТ-инфраструктуры. Поэтому, когда меня пригласили в одну из таких фирм помочь настроить бухгалтерию и поправить «что-то там в домене», я предполагал обойтись установкой терминального сервера и очисткой MS Active Directory. Но все сложилось совершенно по-другому.

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

Сетевая инфраструктура включала 14 рабочих станций (MS Windows 2000/XP/7) и выделенный сервер (MS Windows 2000 Server + MS SQL 2000 + MS Exchange 5.5).

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

Можно было, конечно, просто уйти, но меня задело явное пренебрежение главного бухгалтера – такого отношения к ИТ-специалистам я давно не встречал. И тогда я предложил провести недорогую модернизацию, которая в течение одного – трех месяцев уменьшит расходы предприятия на 15-20% и поднимет продажи. В случае успеха предприятие получает реальную выгоду, в случае неудачи – отлаженную ИТ-инфраструктуру. Сделка состоялась, несмотря на едкие замечания главного бухгалтера.

Развертывание дата-центра и формирование SaaS

Первым делом я попросил уволить студента, выполнявшего функции ИТ-администратора (экономия – 2000 рублей в месяц). Потом, сняв образ существующего Windows-сервера, отправился в ближайший компьютерный магазин покупать комплектующие для будущего дата-центра.

Идея создания SaaS (Server as a Service) для небольшого предприятия появилась у меня довольно давно, но вот реализовать ее все не получалось. А тут и время есть, и начальный капитал для реализации. Суть идеи была довольно проста – создание хостовой системы с несколькими виртуальными серверами. Каждый виртуальный сервер несет определенную информационную нагрузку и может быть отлажен или заменен отдельно от других.

После небольших прикидок по вероятной нагрузке была выбрана следующая аппаратная конфигурация, указанная в таблице 1.

Таблица 1. Стоимость сервера

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

В качестве хостовой системы был установлен Red Hat Enterprise Linux 6.1 (далее по тексту – RHEL) [1], поскольку, кроме платформы для виртуальных серверов, требовались системы резервирования данных и управления электропитанием.

Рисунок 1. Упрощенная схема локальной сети малого предприятия

На аппаратном уровне был сформирован RAID-1 (зеркало). Разбиение дисков и типы файловых систем следующие:

• /boot – 200 Мб (EXT4);
• swap – 12 Гб (SWAP);
• vg00 – 1350 Гб:
  • / – 30 Гб (EXT4);
  • /var/spool – 60 Гб (ReiserFS);
  • /usr – 30 Гб (EXT4);
  • /var – 60 Гб (EXT4);
  • /VirtualMachines – 1197 Гб (XFS).

Структура логических томов была выбрана намеренно, поскольку LVM позволят реконфигурировать и делать резервные снимки томов. Файловая система XFS отлично работает с файлами большого размера, а ReiserFS – с большим количеством мелких файлов [2-4].

На хостовом сервере были установлены:

• базовые сетевые службы: DNS и NTP;
• для удаленного управления: SSH и TigerVNC;
• виртуализация реализована на связке KVM, LibrVirt и QEMU;
• управление ИБП – на apcupsd.

Все эти пакеты входят в дистрибутив RHEL6.1, поэтому особых настроек не потребовалось.

Развернутые виртуальные серверы предприятия:

Для контроля интернет-трафика и замены MS Active Directory установлен сервер на базе ClearOS 5.2. Портал Horde, входящий в дистрибутив, прекрасно заменил MS Exchange [5]. Ресурсы виртуального сервера: 1 CPU + 512 RAM (далее по тексту – ClearOS).

В качестве файлового сервера и сервера печати использовался сервер MS Windows 2003 Enterprise Edition (RUS). Ресурсы: 1CPU + 1024 RAM (Server).

• В качестве севера бухгалтерии установлен терминальный сервер на основе MS Windows 2003 (ENG) + Citrix 4.0 + MS SQL 2000 + 1Cv7.7 SQL + 1Cv8.2 [6]. Ресурсы: 2-4 CPU + 1024-2048 RAM (в зависимости от ситуации) (SQL).
• Для работы виртуальных серверов в существующей локальной сети на внутренних сетевых интерфейсах сконфигурированы сетевые мосты.
• Виртуальные серверы MS Windows были разделены на два диска (образа). На одном стояла система, на втором размещались данные.

Для Linux-систем изначально формировались локальные репозитории с групповыми пакетами для каждого сервиса. Большая часть групповых пакетов уже имелась в дистрибутивах, остальные пришлось сделать самостоятельно [7].

В качестве системы резервирования на хостовой системе был установлен HP Data Protector Express Single Server Edition (далее по тексту – DP) [8]. Лицензия на него бесплатная при регистрации на сайте. Выбор DP был сделан намеренно, поскольку DP сочетает в себе большие возможности по настройке. Резервирование образов виртуальных машин и RHEL осуществлялось на виртуальную библиотеку, сконфигурированную на внешнем жестком диске.

Образ Disaster Recovery Disk был записан на DVD-ROM. На нем же я оставил файл со всеми паролями и небольшой мануал, который вел при создании дата-центра. Диск был запечатан в конверт и положен в сейф директора.

Система бесперебойного электропитания была построена на двух источниках бесперебойного питания, включенных по каскадной схеме. Это увеличило время автономной работы хостовой системы, необходимое для того, чтобы «уложить» виртуальные серверы при выключении внешнего электропитания.

Рисунок 2. Упрощенная переходная схема локальной сети

Переход на SaaS и смена режима работы предприятия

Внедрение сервисов и смена режима работы предприятия происходила постепенно. Сначала были внедрены Horde и интернет-магазин. Для этого виртуальная машина с ClearOS была выведена в демилитаризованную зону. Сервер зарегистрирован на DynDNS.org, прописана MX-запись. На сервер развернут веб-магазин на базе Joomla [9]. Для привлечения потенциальных покупателей на Google+ открыт профиль предприятия с лентой новостей. Результат был получен сразу в виде экономии на рекламе и начале круглосуточных продаж. Из четырех менеджеров осталось три, по одному на каждое направление и один для координации. Режим их работы – круглосуточный на домашних компьютерах. Экономия за счет смены режима работы и сокращения персонала составила 12 000 рублей в месяц, а доход – более 60 000 рублей в месяц за счет круглосуточных продаж.

Следующим этапом стал сервис бухгалтерии. Для бухгалтеров был организован доступ через Интернет с домашних компьютеров на виртуальный SQL-сервер. Порты Citrix перебрасывались через ClearOS.

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

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

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

Стоимость дополнительного сетевого оборудования приведена в таблице 2.

Таблица 2. Оборудование беспроводной сети

Финальная схема сетевой ИТ-инфраструктуры предприятия показана на рис. 3. Текущий режим работы – круглосуточный интернет-магазин. Технология управления практически процессная, на основе заявок и календаря портала Horde [10].

Рисунок 3. Упрощенная финальная схема локальной сети малого предприятия

Техническая поддержка дата-центра

Вопрос о том, что будет с созданным комплексом после того, как я его закончу, директор задал сразу при нашем первом разговоре, поскольку ни о какой его безотказности речь не шла. В результате было принято решение о разработке «урезанного дерева отказов» (УДО) и составлен график профилактических замен оборудования. Сразу отмечу, что к настоящему моменту эти разработки пока не закончены, поэтому опишу только то, что планируется сделать.

В отличие от классического «дерева отказов» [11] УДО не предполагает поиска неисправностей. В его задачу входит описание действий обычного пользователя, которые с определенной вероятностью позволят восстановить работоспособность комплекса вне зависимости от возникшей проблемы.

УДО содержит всего четыре уровня: диагностика, перезагрузка, восстановление системной части и полное восстановление. Все сервисы в УДО расположены в определенной последовательности. Эта последовательность справа налево отражает примерную их зависимость друг от друга. Чтобы было более понятно, как работает УДО, в таблице 4 показан ее фрагмент.

Практическая реализация УДО выполнена на DP хостовой системы. По умолчанию DP работает от суперпользователя root и может выполнить любой скрипт до начала сессии восстановления и после нее. На компьютере пользователя находится графическая консоль DP, из которой можно запускать сессии восстановления.

К примеру, в случае появления проблем с веб-сервером сотрудник офиса запускает консоль DP и выбирает сессию восстановления «Проверка работы веб-сервера». Эта fake (пустая) сессия, которая содержит два скрипта: один диагностический, выполняемый до начала сессии, и проверочный, выполняемый после сессии.

Диагностический скрипт проверяет работу сервера Apache, базы данных MySQL и доступность 80-го порта сервера ClearOS. Если с сервером все нормально и скрипт отработал без ошибок, сессия будет выполнена успешно. Сотрудник увидит в графическом окне сессии информацию о нормальной работе сервиса и сама сессия будет отмечена зеленым. В случае сбоя диагностический скрипт выполнит перезагрузку сервера Apache и базы данных MySQL.

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

Безусловно, при использовании УДО данные частично будут теряться, но их потеря значительно меньше стоимости содержания системного администратора и времени, затрачиваемого на поиск неисправности.

В таблице 3 приводится график профилактических замен. Он основан на времени наработки, после которого вероятности отказа и нормальной работы оборудования одинаковы. Так называемая наработка (не путайте с MTBF (Mean Time Between Failure) – среднее время между отказами). Его применение должно существенно снизить вероятность отказа комплекса вследствие накопления мелких дефектов оборудования. Нетрудно заметить, что график профилактических замен не предполагает обслуживания или ремонта оборудования, поскольку стоимость работ сторонних специалистов соизмерима со стоимостью самого оборудования.

Таблица 3. График профилактических замен

Таблица 4. Фрагмент УДО с комментариями

***

Я намеренно не стал описывать все технические проблемы, которые возникали в процессе развертывания. В технологии SaaS они решаются довольно быстро, поскольку серверы независимы, и каждый можно настроить отдельно. Гораздо труднее было «сломать» административное сопротивление и отойти от функционального управления. Во многом мне помогли увольнение ИТ-администратора, перевод всей ответственности на себя и, безусловно, полная поддержка со стороны директора предприятия.

1. http://www.redhat.com/rhel/server.
2. http://ru.wikipedia.org/wiki/LVM.
3. http://ru.wikipedia.org/wiki/XFS.
4. http://ru.wikipedia.org/wiki/ReiserFS.
5. http://www.horde.org.
6. http://www.mista.ru/articles1c/terminal.htm.
7. http://fedoriada.ru/?p=323.
8. http://h10010.www1.hp.com/wwpc/ru/ru/sm/WF05a/18964-18964-304618-305392-305392-3436879.html.
9. http://joomla.ru.
10. http://www.club-management.org/content/view/78/22/1/3.
11. http://en.wikipedia.org/wiki/Fault_tree_analysis.

Комментарии могут оставлять только зарегистрированные пользователи