С первого числа мы закрываем возможность установки новых машин. Новых клиентов мы уже прекратили принимать.
Существующие виртуальные машины существующих клиентов будут обслуживаться далее без изменений. Так же просьба не делать «машины про запас» — мы прекратили приём новых клиентов не от добрых обстоятельств.
Причина — мы перешли границы рассчитанных мощностей, а переписывание архитектуры «на ходу» — ужасная практика. В связи с этим решено взять таймаут и перестать гнаться за отделом рекламы (кстати, по этой причине мы и замолкли на Хабре — надеялись чуть снизить поток приходящих). Однако, люди приходили — и доходило до смешного, в одной из долго и тщательно выписываемых компонент мы закладывались на потолок в приблизительно 10к коннектов. Тестирование/исправление (процесс preproduction) затянулся на месяц… И к моменту, когда мы выкатили эту компоненту, оказалось, что она уже «в притык» (6-9к коннектов в секунду). А ведь писали мы её несколько месяцев!
И стало очевидно, что мы просто не справляемся. Решение о прекращении приёма новых клиентов далось не сильно легко (ну вы понимаете, споры в стиле «а с чего вам зарплату платить?» и т.д.), но здравый технический смысл победил здоровуюжадн устремлённость к успеху компании.
Сколько займёт переработка? Планируемый срок — около 2-3 месяцев, сколько реально потребуется — не знаю. Во-первых, потому что придётся серьёзно переделывать архитектуру, централизованные БД окончательно будут удалены; децентрализация всего и вся — задача крайне нетривиальная.
С большой вероятностью мы не сможем изменить существующую конфигурацию, так что будет запущена вторая копия облака. Как будет выглядеть миграция клиентов из первой во вторую — опять же, не знаю (пока даже не думал).
Теперь об авариях. Да, нам так повезло, что произошли три несвязные аварии подряд. Одна в воскресенье, вторая во вторник, третья в пятницу. Кто виноват? Ну, зависит от того, кто спрашивает, но по-сути — мы. Все отказы были связаны с программным обеспечением (не нашим); мы даже не можем кивать в сторону кривых электриков, уборщиц и прочих козлов отпущения.
Для тех, кому интересно, как это выглядит (извините за качество, не до качественной съёмки было):
Авария 1 — 150 клиентов:
Аптайм на момент аварии — 4 месяцев 24 дня. С момента ввода в эксплутацию первый сбой.
Авария 2 — 391 клиент:
Аптайм — 6 месяцев 4 дня (с момента предыдущей аварии. Тогда из-за бага в NFS-сервере пришлось принудительно перезагрузить все виртуальные машины и просить людей убрать упоминание NFS из /etc/fstab).
Авария 3 — 398 клиентов.
То же самое хранилище; Аптайм на момент аварии — 2 дня 4 часа.
Устранение подобных узких мест — вторая задача, которую мы будем решать во время взятого таймаута.
В предполагаемой нами модели хранения клиентских данных мы не рассчитывали на полное и безоговорочное прекращение работы ядра системы. Контролируемую перезагрузку, падение конкретных сервисов, смерть дисков в многократно резервированном рейде (и даже смерть SAS-контроллера) мы предусматривали. А вот такого «доброго» нет.
Это была наша ошибка. И за эту ошибку отвечаю я, так как я положился на то, что мы хотя бы сможем узнать об остановке работы сервиса. В ходе работ над облаком это будет одна из основных задач, над которыми я буду работать.
Когда случается авария, то клиенты начинают делать множество телодвижений. Перезапускать машины, пытаться их многократно включить и выключить.
Визуально ничего не происходит, на на самом деле, внутри, система-то всё помнит. В результате очередь задач для некоторых машин доходит до 50-100 задач. И если мы научились объединять одинаковые задачи (если клиент попросил ребут три раза, значит нужно всего лишь один раз перезагрузить), то разнобой задач всё-таки выполняется как сказали. Да, если вы сказали перезагрузить машину, выключить, включить, перезагрузить, выключить и включить, то именно так и будет сделано.
А когда таких клиентов несколько сотен… Получается неприятно. Особенно, когда все запросы приходят почти одновременно. У мастера пула банальным образом не хватало ресурсов. То есть 800% загрузки процессора и очередь на несколько сотен заданий.
А вот разделять мастера пула на нескольких мы просто не готовы совсем. Пока что. Это одна из задач с которой мы будем думать.
upd: статью опубликовали без моего участия, картинки будут завтра.
Существующие виртуальные машины существующих клиентов будут обслуживаться далее без изменений. Так же просьба не делать «машины про запас» — мы прекратили приём новых клиентов не от добрых обстоятельств.
Причина — мы перешли границы рассчитанных мощностей, а переписывание архитектуры «на ходу» — ужасная практика. В связи с этим решено взять таймаут и перестать гнаться за отделом рекламы (кстати, по этой причине мы и замолкли на Хабре — надеялись чуть снизить поток приходящих). Однако, люди приходили — и доходило до смешного, в одной из долго и тщательно выписываемых компонент мы закладывались на потолок в приблизительно 10к коннектов. Тестирование/исправление (процесс preproduction) затянулся на месяц… И к моменту, когда мы выкатили эту компоненту, оказалось, что она уже «в притык» (6-9к коннектов в секунду). А ведь писали мы её несколько месяцев!
И стало очевидно, что мы просто не справляемся. Решение о прекращении приёма новых клиентов далось не сильно легко (ну вы понимаете, споры в стиле «а с чего вам зарплату платить?» и т.д.), но здравый технический смысл победил здоровую
Сколько займёт переработка? Планируемый срок — около 2-3 месяцев, сколько реально потребуется — не знаю. Во-первых, потому что придётся серьёзно переделывать архитектуру, централизованные БД окончательно будут удалены; децентрализация всего и вся — задача крайне нетривиальная.
С большой вероятностью мы не сможем изменить существующую конфигурацию, так что будет запущена вторая копия облака. Как будет выглядеть миграция клиентов из первой во вторую — опять же, не знаю (пока даже не думал).
read error
Теперь об авариях. Да, нам так повезло, что произошли три несвязные аварии подряд. Одна в воскресенье, вторая во вторник, третья в пятницу. Кто виноват? Ну, зависит от того, кто спрашивает, но по-сути — мы. Все отказы были связаны с программным обеспечением (не нашим); мы даже не можем кивать в сторону кривых электриков, уборщиц и прочих козлов отпущения.
Для тех, кому интересно, как это выглядит (извините за качество, не до качественной съёмки было):
Авария 1 — 150 клиентов:
Аптайм на момент аварии — 4 месяцев 24 дня. С момента ввода в эксплутацию первый сбой.
Авария 2 — 391 клиент:
Аптайм — 6 месяцев 4 дня (с момента предыдущей аварии. Тогда из-за бага в NFS-сервере пришлось принудительно перезагрузить все виртуальные машины и просить людей убрать упоминание NFS из /etc/fstab).
Авария 3 — 398 клиентов.
То же самое хранилище; Аптайм на момент аварии — 2 дня 4 часа.
Устранение подобных узких мест — вторая задача, которую мы будем решать во время взятого таймаута.
В предполагаемой нами модели хранения клиентских данных мы не рассчитывали на полное и безоговорочное прекращение работы ядра системы. Контролируемую перезагрузку, падение конкретных сервисов, смерть дисков в многократно резервированном рейде (и даже смерть SAS-контроллера) мы предусматривали. А вот такого «доброго» нет.
Это была наша ошибка. И за эту ошибку отвечаю я, так как я положился на то, что мы хотя бы сможем узнать об остановке работы сервиса. В ходе работ над облаком это будет одна из основных задач, над которыми я буду работать.
А в чём проблема?
Когда случается авария, то клиенты начинают делать множество телодвижений. Перезапускать машины, пытаться их многократно включить и выключить.
Визуально ничего не происходит, на на самом деле, внутри, система-то всё помнит. В результате очередь задач для некоторых машин доходит до 50-100 задач. И если мы научились объединять одинаковые задачи (если клиент попросил ребут три раза, значит нужно всего лишь один раз перезагрузить), то разнобой задач всё-таки выполняется как сказали. Да, если вы сказали перезагрузить машину, выключить, включить, перезагрузить, выключить и включить, то именно так и будет сделано.
А когда таких клиентов несколько сотен… Получается неприятно. Особенно, когда все запросы приходят почти одновременно. У мастера пула банальным образом не хватало ресурсов. То есть 800% загрузки процессора и очередь на несколько сотен заданий.
А вот разделять мастера пула на нескольких мы просто не готовы совсем. Пока что. Это одна из задач с которой мы будем думать.
upd: статью опубликовали без моего участия, картинки будут завтра.
