Когда я устроился на новую работу, передо мной была поставлена первая задача — разобраться, почему один из экземпляров SQL очень сильно нагружает диски. И предпринять необходимые действия для устранения этой ужасной проблемы. Я еще не сказал, что дисковый пул был всего один, и что при нагрузке на диски страдали все экземпляры сиквела? Так вот это было так. Что самое главное, как оказалось, мониторинг в лице Zabbix не собирал необходимые метрики, а на добавление оных нужно было заводить заявку и ждать. Ждать и смотреть, как «горит» дисковый массив. Или…

Было решено отправить заявку в путешествие сквозь шестерни бюрократического механизма и делать свой, временный мониторинг.

Для начала создадим БД и объекты, необходимые для сбора метрик производительности SQL-сервера.

История о том, как у меня была задача на решение которой ушло 2 дня. Обнаружилось несоответствие в документации и реальном мире яндекс облака в Яндекс писалось, но ответа не получилось.

Yandex.Cloud

Задача:

По расписанию, создавать SNAPSHOT дисков в используемых instance. При этом должна быть возможность помечать диски, которые нужно подвергать процедуре резервного копирования, а какие нет.

Подзадачи:

• Snapshot’ы старше n дней должны автоматически удаляться из хранилища. При этом должна быть возможность изменять n.
• Snapshot’ы должны иметь человеко-читаемый вид названия. И соответствовать следующему шаблону:
  
  

  %имя диска оригинала%-дата создания%-%уникальное имя диска%

Для того, чтобы в случае необходимости, человеку было очевидно из чего разворачивать новые машины. (в финальном варианте реализовано отдельным bash скриптом исполняемым со сторонней машины).