Комментарии 22
А вы правда используете Backup Exec для «тысяч серверов» и по вашему мнению этот софт действительно является «одним из основных»?
кстати, уже года три и Backup Exec и NetBackup — снова Veritas.
Странная статья, с образом специалиста с двадцатилетним стажем в СРК никак не соотносящаяся.
Но, конечно, Bckup Exec здесь еще смешнее выглядит.
В целом, мне кажется, что пост писал человек, к бекапам имеющий мало отношения. Одна фраза «процесс практически не оказывает влияния на производительность самой виртуальной машины» говорит о полной некомпетентности её автора.
Одна фраза «процесс практически не оказывает влияния на производительность самой виртуальной машины» говорит о полной некомпетентности её автора.Я бы не был так категоричен. Снятие бэкапа с снапшота сделанного на уровне СДХ и который льется напрямую в хранилку с дедупликацией на лету, особенно если СХД это реплика — вообще никак не влияют на прод.
На allflash решениях можно прогонять это через бэкап прокси, если тот находится на отдельных от продовских вычислительных ресурсах почти по классической схеме. А если СРК еще и умеет application aware, то даже сброс кэша скуля на диски не всегда нужен. СРК сама его дописывает из логов транзакций.
Во-первых, чтение со снепшота априори влияет на боевые диски операциями чтения. СХД-реплика поможет, но я не встречал в бою схем бекапа VMWare с реплики.
Во-вторых влияние на VMWare будет на стадии коммита снепшота, и чем дольше бекап — тем сильнее.
В-третьих, если на машине что-то более сложное чем mssql, например Oracle, будет влияние между begin и end backup.
Да, это не всегда заметно. Тем не менее, говорить что влияния нет — нельзя. Эта вредная мысль запоминается менеджерами, которые потом приходят с глупыми идеями.
Для компенсации этих эффектов придумываются совершенно безумные схемы — взять хотя бы схему бывшего EMC с их IO Splitter и прочими RecoverPoint for VM. Если бы влияния не было — все это бы не понадобилось.
СХД предназначена для постоянной записи и чтения, и если вы умудряетесь выбирать 24х7 потолок иопсов с СХД или полосы FC, у Вас первоочередная проблема не в бэкапах.
Разве снепшот СХД без снепшота гипервизора будет консистентным?
все планируемые тормоза лишь заключаются в сбросе кэша базовода на диски и фиксации состояния
Угу, если на СХД CoW-механизм создания снапшотов — то это, конечно, никак не влияет на продуктив, которых на тех же шпинделях вертится. Понятно, что не смертельно, но с другой стороны вендоры СХД, особенно с CoW, и кол-во одновременных снапшотов лимитируют, а для высоконагруженных томов и вовсе не советуют их использовать. Тут где-то есть статья авторства KorP, можно поискать и почитать, интересно.
фиксируя состояние виртуальной машины тем что заставляет сбросить кэши на диск, а дальше
Дальше делается снапшот ВМ средствами гипервизора и только после этого — снапшот средствами СХД.
Ну хотя может это только у Veeam так, а я не в курсе.
Если взять тот же самый Veeam, то вот статья пятилетней давности в корпоративном блоге. Там рассказано достаточно внятно что я имею в виду. А вот тут, можно почитать почти тоже самое, но посвежее от инженера NetApp.
Уверен, что за три года все стало только лучше.
Что до ваших ссылок — там точно так же сказано, что сначала будет снапшот ВМ выполнен.
Что до ваших ссылок — там точно так же сказано, что сначала будет снапшот ВМ выполнен.Точно читали? Тогда скажите мне, где в указанной картинке сделан снапшот ВМ на уровне гипервизора?
Да, будет выполнен снепшот ВМ, который при наличии интеграции с СХД вызовет создание снепшота на СХД. После этого снепшот на уровне гипервизора удаляется. Снепшот на СХД используется для создания бекапа.
Время жизни снепшота на уровне гипервизора несколько минут.
В случае с NetApp, например, снепшоты не влияют на производительность СХД. Плюс для Veeam и Сommvault поддерживается создание бекапов с реплики снепшота на второй СХД. Всем процессом при этом управляет СРК. Репликация асинхронная, передаётся только разница между снепшотами, так еще и выгода от дедупликации и компрессии сохраняется.
Но когда в банке процент виртуализации немалый, легаси системы хоть и есть, но не доминируют числом, а выбор делают в пользу Commvault, лишая виртуализацию шикарной СРК с фичами, которые Commvault'у недоступны под лозунгом «Единая СРК! Единая СРК!» — это
Может, таким людям не стОит админить системы масштабнее локалхоста?..
Самое паршивое, когда читаешь меры по защите, а в курилке за спиной слышишь типа — а, это вендор рассказывает, ему продать надо
Бэкап наготове: разрушаем мифы в честь праздника