Всем привет!
Некоторое время назад я окунулся в мир «сурового энтерпрайза», а именно в ту его область что отвечает за хранение и резервное копирование данных. Точнее говоря в нее больше всего. И за этот срок у меня накопилось несколько правил, которых я стараюсь придерживаться при проектировании или обслуживании решений в этой сфере. Какие-то уже отжили свое, с развитием технологий, а какие-то вполне рабочие. И я решил ими поделиться с вами.
Тут не будет правила 3-2-1, которое часто упоминается и без меня, каких-то прям техник для конкретных ситуаций и прочего в том же духе. Возможно, для большинства из читающих это будут азы и банальности. Это просто мой скромный опыт и надеюсь он будет кому-либо полезен. Прошу под кат.
Рано или поздно возникает потребность получить еще сколько-то терабайтов и/или IOPS'ов. И тогда начинается сайзинг. Часто бессмысленный и беспощадный. Потому что крайне редко кто-то закладывает в сайзинг требования RTO которые обычно предъявляются к резервному копированию. Хотя вроде очевидное требование к любому аппаратному комплексу. Т.е. при сайзинге и формировании требований к новому оборудованию почему-то не учитываются требования системы резервного копирования, которая будет экстренно вам на железо что-то восстанавливать. Иногда что-то весьма большое. Вообще какой-то запас по производительности и месту закладывается, но первое же восстановление данных показывает, что его не хватит на тот жизненный цикл, который был определен для этого оборудования.
За последний год уже дважды видел ситуацию, когда узким местом при восстановлении данных был дисковый массив, на который выполнялось восстановление. В RTO укладывались, но звоночек тревожный.
Именно такую, весьма «энергично» произнесенную фразу, я услышал при общении
с разработчиком одного весьма полезного программного обеспечения для одного бизнеса. Аргументировал разработчик ненужность бекапа для восстановления тем, что решение развернуто на кластере и потому при падении ноды (или дискового массива) на площадке кластер спасет. В этих случаях он, несомненно, спасет. Это вообще отлично, когда есть такие ребята которые думают про отказоустойчивость еще на этапе разработки.
Однако потери данных достигаются не только выходом из строя оборудования на одной площадке, и вот это почему-то долго разработчик понимать не хотел. Как следствие первая версия ПО была выпущена на community СУБД, механики резервного копирования которой не позволяли выполнить ни требования RTO/RPO, ни SLA подрядной организации.
Вообще эту фразу про кластер я слышу довольно часто.
Одной из самых больших моих ошибок было рассмотрение объектов резервного копирования как самостоятельных. Вот СУБД, вот ПО. Это бекапим вот так, а это вот так. Сперва одно, потом другое. И в один прекрасный день мы не смогли восстановиться. Точнее смогли, но за несколько дней, которые были потрачены на устранение ошибок в базе. Причем это не я их устранял, за что мне особенно стыдно. Хотя мы использовали штатный механизм создания резервных копий данной СУБД. Уже протестированный на других системах.
С того момента я везде сую свой нос и трясу разработчика/владельца системы на предмет того, как правильно создавать резервные копии и восстанавливать. Например, в одном случае единственным способом создать рабочую резервную копию была полная остановка служб на 5-и серверах, сделать резервную копию и запустить службы.
Часто сталкиваюсь с решениями на таких СУБД как MySQL и PostgreSQL. И еще чаще сталкиваюсь с ситуацией, когда в качестве метода резервного копирования используется банальный dump базы в /tmp, а потом уже на другой носитель. При этом системы, где применяются эти СУБД, достаточно критичные к времени простоя в случае потери данных, и весьма нагруженные. Я уже молчу про объемы.
Почему-то мало кто читает документацию к этим продуктам и не знает, что есть альтернативные способы и решения создания бекапов этих СУБД. MySQL Enterprise Backup для, соответственно, MySQL и pg_basebackup (pg_start_backup, pg_stop_backup) в, соответственно, PostgreSQL. Или же знает, но вылетело из головы. Хотя эти решения и не сильно сложнее, и быстрее. Быстрее сделать резервную копию, быстрее восстановить, быстрее протестировать.
Некоторое время назад я окунулся в мир «сурового энтерпрайза», а именно в ту его область что отвечает за хранение и резервное копирование данных. Точнее говоря в нее больше всего. И за этот срок у меня накопилось несколько правил, которых я стараюсь придерживаться при проектировании или обслуживании решений в этой сфере. Какие-то уже отжили свое, с развитием технологий, а какие-то вполне рабочие. И я решил ими поделиться с вами.
Тут не будет правила 3-2-1, которое часто упоминается и без меня, каких-то прям техник для конкретных ситуаций и прочего в том же духе. Возможно, для большинства из читающих это будут азы и банальности. Это просто мой скромный опыт и надеюсь он будет кому-либо полезен. Прошу под кат.
Особенности местного «сайзинга»
Рано или поздно возникает потребность получить еще сколько-то терабайтов и/или IOPS'ов. И тогда начинается сайзинг. Часто бессмысленный и беспощадный. Потому что крайне редко кто-то закладывает в сайзинг требования RTO которые обычно предъявляются к резервному копированию. Хотя вроде очевидное требование к любому аппаратному комплексу. Т.е. при сайзинге и формировании требований к новому оборудованию почему-то не учитываются требования системы резервного копирования, которая будет экстренно вам на железо что-то восстанавливать. Иногда что-то весьма большое. Вообще какой-то запас по производительности и месту закладывается, но первое же восстановление данных показывает, что его не хватит на тот жизненный цикл, который был определен для этого оборудования.
За последний год уже дважды видел ситуацию, когда узким местом при восстановлении данных был дисковый массив, на который выполнялось восстановление. В RTO укладывались, но звоночек тревожный.
У нас решение на кластере, зачем вам бекап?!
Именно такую, весьма «энергично» произнесенную фразу, я услышал при общении
с разработчиком одного весьма полезного программного обеспечения для одного бизнеса. Аргументировал разработчик ненужность бекапа для восстановления тем, что решение развернуто на кластере и потому при падении ноды (или дискового массива) на площадке кластер спасет. В этих случаях он, несомненно, спасет. Это вообще отлично, когда есть такие ребята которые думают про отказоустойчивость еще на этапе разработки.
Однако потери данных достигаются не только выходом из строя оборудования на одной площадке, и вот это почему-то долго разработчик понимать не хотел. Как следствие первая версия ПО была выпущена на community СУБД, механики резервного копирования которой не позволяли выполнить ни требования RTO/RPO, ни SLA подрядной организации.
Вообще эту фразу про кластер я слышу довольно часто.
Сперва то, потом сё!
Одной из самых больших моих ошибок было рассмотрение объектов резервного копирования как самостоятельных. Вот СУБД, вот ПО. Это бекапим вот так, а это вот так. Сперва одно, потом другое. И в один прекрасный день мы не смогли восстановиться. Точнее смогли, но за несколько дней, которые были потрачены на устранение ошибок в базе. Причем это не я их устранял, за что мне особенно стыдно. Хотя мы использовали штатный механизм создания резервных копий данной СУБД. Уже протестированный на других системах.
С того момента я везде сую свой нос и трясу разработчика/владельца системы на предмет того, как правильно создавать резервные копии и восстанавливать. Например, в одном случае единственным способом создать рабочую резервную копию была полная остановка служб на 5-и серверах, сделать резервную копию и запустить службы.
Dump наше всё?
Часто сталкиваюсь с решениями на таких СУБД как MySQL и PostgreSQL. И еще чаще сталкиваюсь с ситуацией, когда в качестве метода резервного копирования используется банальный dump базы в /tmp, а потом уже на другой носитель. При этом системы, где применяются эти СУБД, достаточно критичные к времени простоя в случае потери данных, и весьма нагруженные. Я уже молчу про объемы.
Почему-то мало кто читает документацию к этим продуктам и не знает, что есть альтернативные способы и решения создания бекапов этих СУБД. MySQL Enterprise Backup для, соответственно, MySQL и pg_basebackup (pg_start_backup, pg_stop_backup) в, соответственно, PostgreSQL. Или же знает, но вылетело из головы. Хотя эти решения и не сильно сложнее, и быстрее. Быстрее сделать резервную копию, быстрее восстановить, быстрее протестировать.
Please do not shoot the pianist.
He is doing his best.
Oscar Fingal O'Flahertie Wills Wilde
