Практически все активные системы в контрол-плейне построены либо на алгоритмах консенсуса (Raft, Zab), и тогда важно время последнего действия или хартбита, либо на построении текущего актуального состояния (например BGP), которое тоже становится неактуальным при саспенде. Таким образом, восстановление контрол-плейна - это всегда поднятие с нуля и введение упавших нод обратно в кластер.
Поддерживать suspend в дизайне сотен тысяч сервисов не нужная трата ресурсов. Любой важный state - это distriuted state. Остальное - живет локально.
Uptime Institute ставит в основу собственную генерацию, считая это решение универсальным, не раскрывая дизайн национальных сетей электропитания, их отказоустойчивости и т.п.. Uptime Institute смотрит на картинку с т.з. только инфраструктуры датацентров и прав в этом.
Яндекс живет/жил в другой парадигме, традиционно отвечая за все слои: от болта в конструкции ДЦ, до любого процесса в любом контейнере и до последнего байта в клиента. Любые наши сервисы обязаны жить в режиме -1ДЦ.
С появлением нового вида инфраструктурных угроз и нового вида workload - нужны новые решения и к инженерной инфраструктуре, очевидно, мы это решение найдем.
верно.
Говоря о suspend:
Практически все активные системы в контрол-плейне построены либо на алгоритмах консенсуса (Raft, Zab), и тогда важно время последнего действия или хартбита, либо на построении текущего актуального состояния (например BGP), которое тоже становится неактуальным при саспенде. Таким образом, восстановление контрол-плейна - это всегда поднятие с нуля и введение упавших нод обратно в кластер.
Поддерживать suspend в дизайне сотен тысяч сервисов не нужная трата ресурсов. Любой важный state - это distriuted state. Остальное - живет локально.
На самом деле - гораздо чаще, но к счастью, клиенты замечают это реже.
Справедливо, спасибо.
Uptime Institute ставит в основу собственную генерацию, считая это решение универсальным, не раскрывая дизайн национальных сетей электропитания, их отказоустойчивости и т.п.. Uptime Institute смотрит на картинку с т.з. только инфраструктуры датацентров и прав в этом.
Яндекс живет/жил в другой парадигме, традиционно отвечая за все слои: от болта в конструкции ДЦ, до любого процесса в любом контейнере и до последнего байта в клиента. Любые наши сервисы обязаны жить в режиме -1ДЦ.
С появлением нового вида инфраструктурных угроз и нового вида workload - нужны новые решения и к инженерной инфраструктуре, очевидно, мы это решение найдем.
Запрос в компанию провайдера услуг отправлен, мы ждем ответ от них.
Параллельно, мы обсуждаем возможность дополнительного резервирования питания для тех модулей, жители которых могут не пережить режим -1 ДЦ.