Кратко

  • 5 сентября в Azure Databricks сообщили о двух отдельных инцидентах в регионе Central US; оба затронули запуск вычислительных ресурсов и выполнение заданий
  • Оба инцидента были устранены, однако доступные отчёты о состоянии сервиса не позволяют установить, была ли у них общая причина

Факты

5 сентября в Azure Databricks сообщили о двух отдельных сбоях сервиса в регионе Central US. Первый, ES-2194668, затронул Classic Compute, Declarative Pipelines и Jobs. Сообщалось об ошибках запуска кластеров, зависании кластеров в состояниях Pending или Starting, ошибках подключения блокнотов, а также о заданиях и конвейерах, которые завершались с ошибкой или выполнялись с задержкой. Система отслеживания состояния фиксировала инцидент более двух часов.

Позднее второй инцидент, ES-2195009, затронул Compute и Unity Catalog в регионе Central US. Клиенты вновь столкнулись с ошибками запуска кластеров и подключения блокнотов, а также со сбоями или зависанием заданий во время запуска вычислительных ресурсов. Инцидент устранили в течение часа.

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

Оценка

В обоих случаях работа останавливалась на этапе, когда Databricks должен был выделить вычислительные ресурсы. Данные, код и блокноты клиента могли по-прежнему находиться на платформе, но запланированное задание не могло запуститься, если его кластер оставался в состоянии Pending или Starting. Это означает, что запуск кластера — отдельная зависимость, помимо самого хранения данных на платформе.

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

Для читателей BTW главный вывод таков: командам, использующим управляемые вычислительные ресурсы, нужно знать, какие задания могут ждать, а какие — нет. От этого зависит, достаточно ли простых повторных запусков или следует заранее подготовить другой регион.

За чем следить

Следите за отдельными сведениями о первопричинах ES-2194668 и ES-2195009, новыми инцидентами с вычислительными ресурсами в Central US и рекомендациями Databricks по повторным попыткам или восстановлению в другом регионе. Для клиентов важным показателем будет то, смогут ли критически важные задания корректно возобновиться после перерыва или быть перенесены в другой регион, если запуск вычислительных ресурсов останется недоступен.

Источники