В работе 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% отвалится то не критично и макс на час два, а вот относительно бюджетных вариантов я не знаю.
——-
Ого.
> силами 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 день к отпуску в год.
>>>Да сложнее строить сеть, да скорее всего между ними будет или не очень надёжный публичный интернет или дорогой приватный.
Это я в основном про обеспечение какой-либо репликации между ДЦ. Часто этот трафик упускают, а там могут быть большие пики.
>В нормальных условиях хватает 5
> Мы приняли решение в пятницу переносит все данные в Amazon в Германию.
А как там №152-ФЗ??
Народ пишет что до сих пор не работает. Жесть.
Про переезд в Германию предупреждают заранее, чтобы снять с себя ответственность перед № 152-ФЗ. Мол пользователи знали что мы у фашистов мы их за уши не тянули. Ну а по сути клиенты будут виноваты, что размещают свои и чужие ПД на заграничных серверах.
>Это они у нас столько расходятся почему-то. В нормальных условиях хватает 5-10 минут.
Когда смотришь по метрике, то трафик восстанавливается за 24 часа обычно, видимо такой кэш dns у региональных провайдеров
>А почему не хватает шареда-
Потому что своя CRM, рассылка и еще куча чего, нужен стабильных отклик без поправок на час пик. Даже VPS не подходит, у соседей будет пик и ты это тоже заметишь.
В общем экономия на серваке нужна если бизнес это сапа и директ, а так это экономия на спичках
>1. Добавить А-записи на альтернативные ДЦ вполне себе бюджетно.
Сам так не пробовал, но как я понял по прочитанному, все ломятся на основной IP а уже потом пытаются на альтернативные, все равно идет потеря почти всего трафика.
>3. Сделать п. 2 на основе облаков тоже недорого. Насколько я знаю это тот же VPS только с резиновыми параметрами, т.е. вся не предсказуемость VPS фактически сохраняется, поправьте если заблуждаюсь.
>А как там 152-ФЗ-
У нас так пол бизнеса работает, сами даже не знают чего именно нарушают, при проверке им все расскажут, правда вероятность такой проверки стремиться к нулю.
Но я бы в Германию или еще в какую заграницу не переносил проект, отклик не стабильный, а часто стабильно долгий, сайт будет открываться по любому медленно, так как каналы связи не очень толстые, также если кого то ддосить начнут то в первую очередь именно иностранный трафик режут, в общем даже без учета 152-ФЗ это глупо делать, иностранные хостеры хороши тем у кого бизнеса это сапа и директ, потому как дешево.
>Народ пишет что до сих пор не работает. Жесть.
Какие то особо тупорылые, нормальный хостер исправляет даже самую трудную проблему в течении 3-5 часов, задержка более 12 часов это какой то апокалипсис который допустим раз в 10 лет, если более суток простой, то значит надо менять хостера, потому как у них здание сгорело начисто.
Хостеров попробовал не мало в свое время, рекомендую арендовать сервер у мастерхост, причем именно с их администрированием, у них интересная система, на твой арендованный сервер ставится их система виртуального хостинга, у тебя получается виртуальных хостинг только в пределах своего сервера, root не дают, но по просьбе открывают команду top чтоб можно было отслеживать нагрузку на сервак, так же по запросу могут поставить специфическую библиотеку если она не противоречит их политике безопасности.
Фишка их системы в том что конкретный администратор не имеет доступа к именно твоему серверу в процессе работы, все действия необходимые для администрирования и обновлений ПО делаются в рамках их хостинговой среды централизованно, мониторинг работоспособности также делается через нее же, это хороший подход если вы хотите минимизировать кражу данных с вашего сервера, потому как если даже слив и произойдет то они легко установят кто имел доступ и что именно делал в ручном режиме, но такой доступ им дается только в рамках твоего же обращения чтоб например библиотеку какую поставить.
> Мы приняли решение в пятницу переносит все данные в Amazon в Германию
Как-то до чуваков вообще плохо доходит )))
Они правда собрались всех своих клиентов подставить под 152-ФЗ???
А клиенты в курсе что они будут закон нарушать автоматически?
Причем именно клиенты и будут нарушителями а не сам битрикс…
Какие то отмороженные ребята, может насмотрелись на то как Жаров не может уговорить гугл и фейсбук на соблюдение 152-ФЗ, но что то мне кажется с клиентами битрикса РКН не будет церемониться, как не стал с линкидом, пара забаненых РКН-ом клиентов и с битрикса начнется паническое бегство.
Да и ping с амазона много больше получится!
Куда только смотрят их акционеры…
>Развернуть новую структуру из 300 серверов в России за выходные
> невозможно технически и организационно
Плоховато смотрели…
У Мегафона есть пустое облако, легко бы там развернулись… не скажу правда что вот прям было бы им там легко, скорее наоборот намудохались бы по полной, но в принципе это возможно, хоть и очевидно проигрывает по всем статьям Amazon… Но действительно хотелось бы услышать коменты от Битрикс про 152-ФЗ
А кто виноват кроме Битрикса? В шапке сайта хостера написано «Облачные сервисы и услуги недорого в Москве..». Ну недорого же.