«Битрикс24» не доступен у 30% пользователей, виноват хостинг (обновлено: «Битрикс24» переезжает на хостинг Amazon)
В работе CRM-системы «Битрикс24» произошёл сбой, сообщила компания.
В данный момент около 30% пользователей «Битрикс24» в России столкнулись с перебоями в работе сервиса. Проблема появилась в полночь с 8 на 9 февраля. Причина — выход из строя сетевого оборудования «Корп Софт» — хостинг-провайдера российской части нашего сервиса. Несмотря на все заранее предпринятые нами меры по обеспечению бесперебойной работы инфраструктуры, из-за ошибки проектирования сети у провайдера сломался коммутатор, который вывел из строя оба зарезервированных дата-центра, - говорится в сообщении "Битрикс24".
Глава "Битрикса" Сергей Рыжков написал эмоциональный пост в своем Facebook:
Как же меня задолбал этот российский хостинг! Один сраный коммутатор выводит из строя два абсолютно и совершенно независимых до этой ночи датацентра! Ну как? Нахрена платить за полный резерв железа, проводить учения, подписывать договора, чтобы потом услышать «мы не знаем как такое могло получиться».
Клиенты компании продолжают сообщать о проблемах, несмотря на то, что "Битрикс24" обещала устранить неисправность максимально оперативно. Из комментариев следует, что у части клиентов "Битрикс24" не работает также телефония.
На момент выхода статьи "Роем!" не удалось связаться с компанией «Корп Софт», сайт компании также недоступен.
Обновлено 12.02.2018, 11:00: «Битрикс24» сообщил, что «Корп Софт» так и не смог предоставить адекватного решения проблемы, в результате чего запущен переезд сервиса на сервера компании Amazon в Германии.
В пятницу в результате аварии выяснилось, что основной и резервный датацентр в компании Корпсофт, где расположен Битрикс24 в России, связаны между собой и авария в одном из них выводит из строя резервный датацентр.
Развернуть новую структуру из 300 серверов в России за выходные невозможно технически и организационно. Мы приняли решение в пятницу переносит все данные в Amazon в Германию. Очень сложная идея, но единственно возможная. За выходные мы развернули в Amazon новое оборудование и инфраструктуру. Все подготовили. Начали перенос и опять столкнулись с проблемами Корпсофта.
С утра понедельника опять авария в Корпсофта. Опять нет связанности и оба датацентра работают с перебоями. Зацепило опять же примерно 30% клиентов. Перенос проектов в Амазон мы продолжаем. Стараемся сделать все возможное и невозможное. Сейчас по плану в первую очередь будут перенесены коммерческие Клиенты. Перенос будет проявляться в отключении на 5-10 минут и возобновлении работы уже в другом датацентр, - написал в своем Facebook Сергей Рыжиков.
Добавить 17 комментариев
Вообще все молодцы. Даже интересно стало насколько рухнет малый рубизнес, если Корп Софт наэфесбучит какой-нибудь чеченский омбудсмен по интернетикам.
Да не посты надо писать Рыжкову, а в суд подавать и требовать вернуть ВСЕ деньги ранее уплаченные Битриксом за резевный ЦОД (который как оказалось был блефом) + компенсацию … Ну и остальным клиентам этого горе хостинга также. Одни вылетят в трубу, другие задумаются как лапшу на уши вешать клиентам про бесперебойную работу и резерв всего…
>> Один сраный коммутатор выводит из строя два абсолютно и совершенно независимых до этой ночи датацентра Не такие то они уж и независимые, если там общий коммутатор. Да и вообще один поставщик услуг это так себе надёжность по административным причинам.
Вот для исключения подобного и надо брать два совершенно разных юридически и физически ДЦ. Да сложнее строить сеть, да скорее всего между ними будет или не очень надёжный публичный интернет или дорогой приватный. Собственно я строил такие системы и это тоже ничего не гарантирует. Но это хотябы не даст совершать простых, но ривых решений вроде общего L2 (кольцо в одном ДЦ и привет хоть остальному одному, хоть двум, хоть трём остальным)
>Да сложнее строить сеть, да скорее всего между ними будет или не очень надёжный публичный интернет или дорогой приватный. >Собственно я строил такие системы и это тоже ничего не гарантирует.
Разрешите полюбопытствовать, как именно балансировали нагрузку, ведь только силами dns это не очень то и получается, а если как то по другому, то все равно будет узкое место, при крахе которого все также будет лежать.
Я даже согласен вообще не балансировать нагрузку, а тупо держать резервный сервер в другом датацентре под парами, но как автоматом перебрасывать ВЕСЬ трафик без посредника, который также может лечь, если силами dns то сутки будут все равно потеряны. Приличные хостеры так долго не лежат, макс несколько часов, у мастерхоста например на моей памяти такая авария только один раз была, обычно все в пределах часа и то очень редко.
PS Удивительная глупость все в одну корзину класть, сайт и телефонию, у меня например в здании сейчас только два оптоволоконного интернета и я как будет возможность сразу заведу третий, а вот как сайт сделать сверх надежным не знаю, пока тупо использую на мой взгляд самый надежный датацентр — masterhost и сервер с десятикратным запасом производительности.
PS2 Как это за очень дорого вопрос решают крупные проекты я знаю, но и они не имеют гарантии сохранности 100% трафика, у них если и 10% отвалится то не критично и макс на час два, а вот относительно бюджетных вариантов я не знаю.
на мой взгляд самый надежный датацентр — masterhost
> силами dns то сутки будут все равно потеряны Это они у нас столько расходятся почему-то. В нормальных условиях хватает 5-10 минут.
> пока тупо использую на мой взгляд самый надежный > датацентр — masterhost и сервер с десятикратным > запасом производительности А почему не хватает шареда?
> PS2 Как это за очень дорого вопрос решают крупные проекты я знаю 1. Добавить А-записи на альтернативные ДЦ вполне себе бюджетно. 2. Привязать каждого клиента к отдельному поддомену и роутить их на 10 дц вполне себе бюджетно. 3. Сделать п.2 на основе облаков тоже недорого. И т. д. и т. п.
>> Разрешите полюбопытствовать, как именно балансировали нагрузку Прежде всего, проектировалось только под избежание вот таких вот проблем, как описано в посте. 10-20 минут простоя при вводе резерва допустимы, но в итоге всё оказалось даже лучше.
Вариантов делал несколько: у всех плюсы и минусы 1. Bgp* — анонсировать блок IP либо в AS1 либо в AS2 (уверен, вам интересен как раз этот) 2. DNS + резервный поддомен о котором все пользователи уведомлены (в моём случае автоматически выбирается внутри ПО которое работает с системой как с API), пользователи которые работают через браузер имеют на рабочем месте инструкции. (не очень для веб-проектов, но TTL=300 вполне годно если резолвер провайдера не закручен как шестёрка на техосмотр, множественные A записи уже упоминали) 3. На проксе типа cloudflare/куратор (и единая точка отказа переезжает на проксю и её связность с двумя ДЦ)
1 и 2 можно совместно. Один ДЦ рабоатет в подсети А/24 анонсируемой в AS1 второй B/24 в AS2 myapp.mydomain смотрин на IP из подсети A, myapp-backup.mydomain на IP из подсети B. У 4 человек и в «NOC» есть по аварийному конверту которым все умеют пользоваться, у меня даже где-то лежит один на память с устаревшими паролями. При отказе первого ДЦ IP переезжают из AS1 в AS2, перещелкивается DNS на IP из B. Итого: доступность по старому IP для 90% пользователей — 1-3минуты. Мне известно про 4 тестовых переключения, и два боевых(одно боевое-боевое, второе «всё равно planned maint на час, давайте веселиться» ). +Выяснено что переключения на уровне DNS были в принципе излишними.
*) При этом схема описанная мной с BGP хорошая, но можно и лучше. Уже без меня меняли на /23 в AS1, при проблемах добавляется more specific /24 на AS2, также вроде есть какая-то встроенная функциональность BGP под это.
Вообще считаю схему даже с насколько угодно костыльным BGP подходящей для больших SAAS-ов типа битрикса.
Я вообще больше специалист про вебсервисам и всякому такому и долго боялся в bgp влезать и представлял это только теоретически но очень хотел сделать и случайно проговорился на встрече, но это оказалось не так сложно, сетевики заказчика ссали в основном из-за бюджета и идею поддержали очень охотно, экспериментальная для всех там присутствовавших конструкция с IP оплаченными на месяц произвела хорошее впечатление, бюджет был выдан. Также был маленький тестовый контур для внутренних учений из старого железа. Вроде даже каждый из имеющих доступ к конверту обязан был раз 2 месяца делать это всё в тестовой среде. За держание конверта был маленький бонус + 1 день к отпуску в год.
>>>Да сложнее строить сеть, да скорее всего между ними будет или не очень надёжный публичный интернет или дорогой приватный. Это я в основном про обеспечение какой-либо репликации между ДЦ. Часто этот трафик упускают, а там могут быть большие пики.