Рекомендуется ли регулярно делать снимки рабочих серверов. Я читаю много веб-сайтов, которые предлагают не делать снимки производственных систем, заявляя, что это может повлиять на производительность сети и машины. Кто-нибудь знает об этом?
Имейте в виду, что снимки не замена бэкапам! Снимки использую только для создания короткий срок точки восстановления, например прежде чем сервер будет исправлен чем-то, что может его сломать. Но я не буду хранить снимки дольше нескольких дней, и ни в коем случае не буду создавать их на регулярной основе, просто потому, что они могут мне понадобиться позже.
Обратите внимание, что большинство программ резервного копирования, поддерживающих виртуализацию, также используют моментальные снимки автоматически, чтобы привести виртуальную машину в согласованное состояние только для чтения перед ее резервным копированием. Но даже в этом случае моментальный снимок снова удаляется, как только задание резервного копирования завершается.
Моментальные снимки не предназначены для регулярных проверок и не являются решениями для резервного копирования. У вас может быть несколько проблем, если их хранить слишком много (например, нехватка места, замедление хранилища и в некоторых случаях также повреждения)
Как правило, производительность диска (и увеличение размера хранилища виртуальной машины) является проблемой для моментальных снимков, поскольку диск теперь разделен между плоским диском и диском для моментальных снимков (возможно, несколько дисков для моментальных снимков); простая операция с диском при отсутствии моментального снимка может значительно раздуться, потенциально требуя работы с данными как на базовом, так и на (нескольких) дисках моментальных снимков (которые не являются смежными с базой или друг с другом; добавление большого дополнительного времени поиска), требуя намного больше времени ввода-вывода, чем на плоском диске.
Оцените производительность вашего диска; если это не повлияет на вас значительно, снимите снимок.
Моментальные снимки можно использовать в качестве механизма для сохранения точки отката при выполнении операций по обслуживанию, но их не следует использовать в качестве механизма резервного копирования виртуальной машины.
Это из лучших практик.
Максимальное поддерживаемое количество снимков в цепочке - 32. Однако VMware рекомендует использовать только 2-3 снимка в цепочке.
Не используйте ни один снимок более 24–72 часов. Моментальные снимки не должны храниться в течение длительного времени для целей управления версиями приложений или виртуальных машин. Это препятствует тому, чтобы моментальные снимки разрастались настолько, что вызывали проблемы при их удалении / фиксации на исходных дисках виртуальной машины. Сделайте снимок, внесите изменения в виртуальную машину и удалите / зафиксируйте снимок, как только вы проверите правильное рабочее состояние виртуальной машины.
Будьте особенно внимательны с использованием моментальных снимков на виртуальных машинах с большим количеством транзакций, таких как серверы электронной почты и баз данных. Эти снимки могут очень быстро увеличиваться в размере, заполняя пространство хранилища данных. Сохраняйте моментальные снимки на этих виртуальных машинах, как только вы проверите правильное рабочее состояние тестируемого процесса..
Чрезмерное количество дельта-файлов в цепочке (вызванное чрезмерным количеством моментальных снимков) или большие дельта-файлы могут привести к снижению производительности виртуальной машины и хоста.
Я ОБОЖАЮ снимки состояния VMWare! Это потрясающая функция для серверов DEV и QA.
На производственной машине наиболее распространенная проблема, которую я слышу от ИТ-персонала, - это занимаемое ими дисковое пространство. Заблаговременное планирование может смягчить это, но в производственной среде всегда есть определенные ограничения. Другими словами, вы можете сделать столько снимков, сколько поместится на ваших дисках.
В большинстве случаев мои клиенты делают снимки только тогда, когда им требуется полная резервная копия среды гостевой ОС. Так, например, мы сделаем снимок перед установкой крупного обновления приложения. Вероятно, мы не будем делать снимок, если виртуальная машина работает с сервером базы данных, а вместо этого просто создадим резервную копию баз данных, используемых внутри.
Как и Шейн выше, я бы сказал, что снижение производительности менее важно, особенно если процессор сервера обычно не привязан, и вы можете запланировать моментальные снимки, которые будут сделаны в непиковое время. YMMV.
Я не вижу здесь упомянутых ВМ оглушает. Если у вас очень загруженный производственный сервер, ваши снимки будут быстро расти. Если защелка открыта в течение какого-то времени, вышеупомянутое вспучивание имеет больший потенциал. Когда вы закрываете этот снимок, существует вероятность прерывания работы служб из-за оглушения.
Когда мне нужно сделать снимок производственной машины, это обычно происходит, когда разработчик обновляет какое-то программное обеспечение на сервере после его тестирования в среде разработки. Привязка будет выполняться в непиковые часы и обычно закрывается в том же периоде обслуживания после успешного обновления.
Производительность сети может быть снижена во время процесса создания моментального снимка. Но, на мой взгляд, небольшой удар по производительности лучше, чем потеря данных. В зависимости от того, насколько важны данные, я, возможно, сделаю это ночью. Если ваши данные не настолько важны, что вы должны делать ежечасно и т. Д.
Только вы можете решить, сколько данных вы можете потерять, если вам потребуется восстановить.
Если вы можете жить со снимком, сделанным 24 часа назад, придерживайтесь его. Но если вам нужны данные не менее чем через час после восстановления, сделайте это.
Мы ежечасно запускаем моментальные снимки для нашего основного сервера базы данных, поскольку они ежечасно меняются. Но наш Exchange Server снимается каждые 12 часов.
Малые и средние серверы с низким уровнем ввода-вывода, тогда да, хорошо. Как уже говорилось выше, контроллеров домена нет, нет, нет! Также зависит от того, запрашиваете ли вы замороженный снимок. При активном сервере БД, например, нехватка памяти / дискового ввода-вывода может а) привести к тайм-ауту и б) вызвать прерывание. Я раньше видел, как Oracle TNS прерывается. Конечно, транзакция восстановилась, но все еще не идеально.
У вас есть три варианта. Первый и самый простой - это делать снимки, однако это не считается официальной задней частью ваших виртуальных машин. Это хорошо для лабораторных сред, но не для производственных виртуальных машин.
Второй вариант - использовать Vmware Data Recovery (VDR). Этот инструмент отлично подходит для малого и среднего бизнеса. Это намного лучше, чем моментальные снимки, но у него есть некоторые ограничения, например, вы можете создавать резервные копии 8 виртуальных машин одновременно. Неплохо, но если у вас сотни виртуальных машин, это не подходит.
Самое профессиональное решение - это тот, кто использует VMWare vStorage API. Такие решения, как Tivoli Storage Manager (TSM), расширяют API vStorage VMWare, чтобы обеспечить решение для резервного копирования виртуальных машин. Есть и другие. Цена, конечно, растет с использованием, но все зависит от того, чем вы хотите заниматься. Я бы либо использовал VDR, либо нашел поставщика решений, который использует vStorage API для резервного копирования и восстановления. Проведите исследование и удачи :)