Записки о софтверном бизнесе

Plan B

February 29th, 2012 Posted in Бизнес, Технологии

На прошедших выходных перестала работать часть сервисов компании Digital River. Для тех кто не в теме - Digital River объединила под своей крышей множество компаний занимающихся приемом оплаты по кредитным картам в онлайне. Им принадлежат RegNow, RegSoft, SWREG, ShareIt, DigiBuy и с десяток других, о которых уже все забыли. Больше других досталось SWREG, который был в дауне 36 часов.

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

Какие из этого следуют выводы:

1. SWREG делает бэкапы, потери данных не было

2. Плана Б у SWREG нет

Тут самое время всем, у кого есть онлайновый бизнес, подумать, что будет с ними подобной ситуации. Что если сломается сервер, на котором рабоатет вебсайт? Что если произойдет пожар в датацентре? Что делать, если перестанет работать прием платежей? Как быстро получится поднять другой сервер в другом месте?

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

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

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

Для дополнительной надежности стоит сервера держать в разных датацентрах. Я пока этого не делаю, слишком мне нравится мой провадйер Hivelocity.

Интересна реакция Digital River на это проишествие. Обычно с ними не так просто связаться в случае каких-то проблем, скажем на сайте SWREG нет в принипе никаких телефонов. Сейчас они опубликовали сразу кучу способов связаться с ними через Twitter, Facebook, LinkedIn и Google+. Помимо этого они дают вендорам один месяц бесплатного сервиса в апреле (у SWREG это 4.5% от суммы продаж). Пустячок, а приятно.

Что еще забавно, один из немногих оставшихся независимых e-commerce провадйеров в нашей индустрии, CleverBridge, тут же разослал письмо счастья клиентам DigitalRiver, предлагая перейти к ним. Как раз тот случай, когда можно оправдать спам.

Все идем работать над планом Б.

 

 

 

 

 

 

 

 

  1. 4 Responses to “Plan B”

  2. By Serge on Mar 7, 2012

    Привет,

    отличная статья, для тех кто понимает, ну просто супер.

    Мы только недавно пришли к виртуальным машинам на дедиках, отличная идея на самом деле. Вопрос изменения данных решаем так:
    1) файлы – собственно сайт и всё что к нему ещё относится, монтируем извне виртуальной машины, так он может храниться где угодно и нормально бэкапиться,
    2) базы – приходится дампить, ничего не поделаешь (по-крайней мере, мы ещё ничего не придумали что с этим делать).

    Вопрос какой – а какую платформу для виртуализации вы используете? Xen? KVM? VirtualBox? Что-то ещё?

    И ещё вопрос – не смотрели, на сколько меньше производительность работы системы на виртуальной машине, по сравнению если бы она работала на самом дедике (без виртуализации)?

    Спасибо ещё раз за очень интересные статьи по теме.

  3. By Кузьма on Mar 8, 2012

    и никаких гарантий не существует, как это не прискорбно, что такая ситуация не повторится в будущем((

  4. By Сергей Корнилов on Mar 8, 2012

    @Serge,

    мы используем ESXi server от VMWare. Он бесплатный и наш хостер может его сам предустановить на сервер, просто удобно.

    По производительности сравнивать трудно, потому что новое железо сильно быстрее старого. Т.е. на сервере с 16гигами памяти и процессором на архитектуре Sandy Bridge все работает значительно быстрее даже на виртулке по сравнению с сервером на Core2Duo и двумя гигами памяти. Сейчас видно, что все 6-7 гигов базы данных SQL Server сидят в памяти и все шевелится очень приятно.

  5. By Serge on Aug 1, 2012

    Привет,

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

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

Post a Comment