Unit-Is — новый дата-центр в Украине. Недорого и надежно.

Да уж, на вас поэкономишь :)

Мы размещаемся на нескольких сайтах по HR и ставка по вакансии в наш дата-центр идет в порядке 10.000 грн. Да, это не топовая зарплата, но вполне адекватная для текущего рынка труда.

А насчет Одессы, вы правы. Это не единственное место, где происходят технические сбои, и, пока что, никакого мистического предзнаменования мы не ощущаем.

Работы по обновлению ПО были запланированы на 3.6.2013 на 23:00. Здесь и далее время по Киеву. Полностью завершить обновление планировалось в течение 2 часов. К сожалению, в результате сбоя, время простоя кластера составило 22 часа.

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

Что планировалось обновлять:

- Nginx

- PHP

- Apache

- MySQL

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

23:00. Остановлены все сервисы, из панели ISPManager Cluster запущены встроенные сервисы обновления. После запуска получен ответ панели о невозможности обновления. В логах были сообщения, что программное обеспечение не найдено.

00:00. Nginx обновлен из официальных источников Debian. Сам nginx запустился без ошибок, после чего ему был предоставлен рабочий конфигурационный файл, с которым он запустился без ошибок.

00:15. После перезапуска сервиса ISPmanager в конфигурационных файлах ispmgr.conf и файлах пользователей apache панелью были внесены автоматические изменения. В логах панели появились записи о том, что сайты не найдены, и они исключаются из конфигурации. Это коснулось, всех доменов. Сайты стали не доступны.

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

Логи панели выглядели следующим образом:

[ 2073:20] ../../src/ispmgr/web/web_apache.cpp:461 TRACE Parse apache config '/usr/local/ispmgr/etc/cluster_apache/users-conf.d/userxxx.inc' and fill up cache 

[ 2073:20] WARNING vhost 'xxx.xxx' not found in main config. Skip it 

При этом, записи присутствовали и в файле конфигурации nginx, и в файлах apache.

00:40 После ошибок произошла отвязка HTTP-ноды и категорический отказ подключения к master-ноде. Панель сообщила в логах, что имеются ошибки в конфигурационных файлах, одновременно с чем продолжала вносить изменения.

Далее начались ошибки вида:

WARNING No record for user '' at shadow. Can't disable

WARNING No record for user '' at shadow. Can't disable

При этом, файл /etc/shadow существовал и записи в нем были корректными.

ERROR Exception 3: 'user'  not exists.

ERROR Exception 4: admin has invalid value

Стоит отметить, что конфигурация ISPmanager, nginx, apache не изменялась.

01:00 Возврат к предыдущим версиям ПО не давал результата. Были опробованы не менее 5-х версий nginx и apache. Ответ панели был неизменным: сайты не найдены, исключаем их из конфигурации.

04:00 Удалены вручную все web-сервисы c master-ноды, включая сам ISPmanager. Результат не изменился. ISPmanager отказывался принимать конфигурационные файлы.

06:00 Продолжение попыток связки nginx + apache + ispmgr, которые, увы, не привели к желаемому результату.

MASTER-нода: полная переустановка, подключение к storage, установка панели: nginx, apache, postfix, dovecot.

16:00 Переустановлены ноды и последние версии ПО. На ноды установили прежние конфигурационные файлы из резервных копий. Панель приняла все конфигурационные файлы и запустилась.

18:00 Запущены все сервисы и 90% сайтов, за исключением небольшого количества сайтов, которые пришлось обрабатывать вручную.

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

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

Руководство дата-центра ЮНИТ-ИС.

Супер специалисты с зарплатой 10 00 грн не удосуживались сделать бекапы перед апгредом :) ? Но нечего главное виновные найдены ...

Ну в общем то вполне понятная ситуация. Только клиентам от этого не легче.

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

Так и Isp.

Ну по крайней мере все максимально открыто и честно, сами знаете, намного лучше вот такое пояснение, чем "были проблемы - все исправлено"..

Интересно было бы конечно услышать какие-либо комментарии со стороны ISPsystem, по этой ситуации..

ISPsystem вообще на мой взгляд не готова обслуживать корпоративных клиентов с серьезными продуктами... продать - продали, а если какой косяк - ждите рабочего дня, администратор посмотрит.

На ISPmanager оно понятно, он стоит копейки, можно и подождать. Но раз продают серьезные продукты, то и поддержка должна быть соответствующей.

UNIT-IS, советую присмотреться к продуктам Parallels. Цены конечно не сравнить, но и качество + обслуживание совершенно иные.

Лет 5 назад нашёл у них 2 серьёзные уязвимости в Plesk'е. Написал в техподдержку

и получил ответ в духе "У вас нет платной техподдержки, поэтому мы вас игнорируем". :)

Ни разу на такое не наталкивался, а опыт работы с их продуктами более 6 лет..

Может ответили, а сами начали проверять? :)

Через год смотрел - изменений не было.

Не советую. Как бывший серебрянный партнер сажу, что их отношение примерно такое:

- Нам нужна фича в Plesk

- Ну может быть мы ее напишем

- Нам она нужна срочно

- Ну может быть разработчики ее напишут за отдельные деньги

- Нам ее надо поддерживать

- Нет, мы ее поддерживать не сможем, заказывайте для каждой новой версии заново

И вариант с DirectAdmin:

- Нам нужна фича в DirectAdmin

- Вы ее можете сделать через это: ссылка, ссылка, ссылка

- Мы хотим ее заказать у вас за деньги!

- Вы можете обратиться к создателям плагинов под DA: ссылка, ссылка, ссылка

В результате заказали фичу у одного из плагинописателей под DA за смешные триста евро, когда для Plesk это оценивали примерно в $8000

После этого я понял, что "русским" бывает не только хостинг.

P.S. Уважаемые россияне, надеюсь вы понимаете что к национальности это отношения не имеет. Такое можно найти в разных странах.