По п.1: обычный (без использования аппаратных снапшотов) бэкап выполняется примерно по следующему алгоритму:
1) Инициируется VMware снапшот. Диск переводится гипервизором в read-only режим. Все изменения на диске начинают записываться в «дельта-файл».
2) Начинается процесс копирования данных с диска в резервную копию (в общем случае) через сеть. Это не быстрый процесс. Все это время операции записи на исходный диск фактически производятся в дельта-файл.
3) После заверешения копирования данных, дается команда на удаление снапшота. При этом выполняется запись всех данных дельта-файла на сам диск, который был все это время в read only режиме. На время этого процесса как раз и происходит фриз — чем больше получился дельта-файл, тем более заметен фриз.
В случае же аппаратных снапшотов алгоритм работы другой:
1) Такой же: инициируется VMware снапшот. Диск переводится гипервизором в read-only режим. Все изменения на диске начинают записываться в «дельта-файл».
2) Инициируется аппаратный снапшот. А это, в отличие от п.2 в предыдущем варианте, быстрый процесс, так как он происходит локально на том же самом дисковом массиве с с оригинальными данными. На время этого процесса, все записи идут в дельта-файл. Дельта файл получается небольшим.
3) Снапшот VMware удаляется. Данные небольшого дельта-файла быстро записываются в основной диск. Дальнейшая работа по копированию данных идет уже с использованием аппаратного снапшота, и без участия виртуальной машины.
Из-за разницы в алгоритмах получается, что фриз во втором случае занимает гораздо меньше времени, чем в первом.
По п.2 — полагаю минимальный период создания аппаратного снапшота зависит от конкретной модели NAS, от параметров виртуальной машины, от состава приложений, которые в ней работают, и от интенсивности дисковых операций записи, которые они производят. Поэтому для каждой системы минимальный период создания снапшотов нужно определять опытным путем.
Интересно, а в Вашей службе техподдержке проводятся опросы клиентов по удовлетворенности качеством обслуживания? Предлагается при закрытии кейса оценить работу техподдержки или т.п.?
Кабель может оказаться перебитым на любом участке «последней мили», кроме того, часто кабели проходят через закрытые от посторонних помещения — поэтому ожидать, что клиент перед звонком в техподдержку будет сам проверять кабель,- как то странно, особенно, если учесть, что техподдержка сразу видит через инструменты мониторинга какой сегмент сети «перестал пинговаться» — то есть ей гораздо проще локализовать проблему, чем неподгтовленному клиенту. К тому же какая разница — ведь в случае с типовым неподготовленным клиентом все равно придется высылать специалиста к нему на дом.
А вообще, перефразируя Евгения Чичваркина: «Техподдержка, если вы говорите, что клиент должен саппортить себя сам,- я заменю вас кнопкой» :)
Теоретически Endpoint Backup может успешно использоваться для серверов в простых сценариях, однако, поскольку, этот продукт позиционируется как продукт для компьютеров домашних пользователей, то мы просто штатно не тестировали его на сценариях с серверами. Скорее всего в простых конфигурациях все пройдет нормально, а в сложных случаях (высоконагруженные сервера, с кластерами и т.д.) — нет гарантий.
У нас в форуме уже задавали такой вопрос: "Active Directory / iSCSI", и там есть хороший ответ, отражающий ситуацию «Yes, simple configurations – but better test it in your environment and share the results with the community :)»
Сложно сказать про планы VMware в этом плане, однако архитектура vVol довольно гибкая: в ней предусмотрены, например, VASA-провайдеры, которые можно реализовать потенциально под любой вид хранилища.
В VEBF такой возможности в готовом виде нет (есть в платных редакциях Veeam Backup, и если VEBF настроен на работу с Veeam Repository, то можно получить автоматическое сохранение в облако).
Но, поскольку нужен именно freeware-вариант, то можно попробовать такой workaround: Google Диск имеет возможность офф-лайн синхронизации выбранных «облачных» папок на компьютер. При его инсталляции на компьютер задается локальная папка на диске, с которой Google Диск будет автоматически синхронизироваться. Вы можете указать в VEBF эту папку Google Диск в качестве пути сохранения резервных копий — и они будут автоматически синхронизироваться с облаком. (Скажу сразу, что этот вариант штатно не тестировался).
У нас нет готового сравнения — набросал несколько преимуществ, которые я увидел:
Расположение резервных копий:
Сетевые папки в Windows Backup поддерживается только в версиях Windows 7 Профессиональная и Максимальная
Ограничения резервного копирования образа системы в Windows Backup: нельзя сохранить образ системы на не NTFS дисках: например, на флэш-накопителе или на CD/DVD-дисках
Параметры расписания: В VEBF можно бэкапить дополнительно (по сравнению с Windows Backup) по таким событиям как:
блокировка компьютера,
Log Off,
при подключении носителя, на который выполняется архивирование (определяется по Volume ID),
кроме того, можно настроить действие при завершении бэкапа по расписанию: например, выключение компьютера или переход в режим сна.
Загрузочный диск восстановления системы: Windows Backup не умеет создавать этот диск в виде ISO файла, а также на флеш накопителе — только на CD/DVD
Схема резервного копирования и управление дисковым пространством, которое занимают резервные копии:
При создании образов системы Windows Backup не применяет компрессию резервных копий.
На сетевых папках Windows Backup всегда использует схему с пересозданием полного образа системы, а на внутренних и внешних дисках всегда используется “бесконечно”—инкрементальная (то есть пока место не закончится будут создаваться инкременты – представьте длительность восстановления и вероятность сбоя из длинной цепочки инкрементов).
В VEBF используется схема с инкрементальными копиями и можно задать конкретное количество сохраняемых точек восстановления
Можно попробовать настроить бэкап всей информации (система и данные) каждые два часа. Продукт использует механизм Change Block Tracking — то есть он будет копировать только измененные блоки данных на диске — если системные файлы за два часа не поменялись (а они обычно меняются нечасто), то и бэкапятся они в этот проход не будут; скорее всего, за два часа изменения произойдут в данных — изменения в них продукт забэкапит. Да, будут некие накладные расходы времени на проверку изменившихся блоков всего диска, но по сравнению со временем копирования измененных данных, они весьма малы. Например, у меня эти накладные расходы составляют всего пару минут для диска в 500ГБ.
Veeam Backup может восстановить как отдельный Exchange сервер, входящий в DAG, так и все сервера, которые в нее входят. Под «традиционными средствами», полагаю, вы понимаете саму технологию DAG? Если так, то отличия у Veeam следующие:
Прежде всего — это решения разного назначения. DAG — это обеспечение отказоустойчивости, а Veeam Backup — резервного копирования (по сути создания долговременного архива). Из этого вытекают последующие пункты списка...
DAG хорошо работает, если «погиб» целый сервер и можно быстро переключить пользователей на другой сервер, где есть копия данных. Если же нужно восстановить отдельное письмо или почтовый ящик, то хотя у DAG и есть свои инструменты гранулярного восстановления, но они ограничены по времени применения (например, в DAG Exchange 2010 отсроченные копии баз хранятся по умолчанию 24 часа).
Если отдельные письма ошибочно удалены пользователем, DAG разнесет это удаление по всем серверам, и уже через 24 часа письмо нельзя будет восстановить. Аналогично с вирусным повреждением писем. Бэкап же позволяет «заглянуть прошлое» на более значительное время, и получить из старой резервной копии оригинальный вариант письма.
Отсроченные базы DAG — это по сути логи инкрементальных изменений. Если их логическая структура хоть немного повредится, будет сложно восстановить целостную копию всей инфосторы Exchange. Полное восстановление сервера с использованием отсроченной базы будет длительным процессом, так как нужно будет «проиграть» все логи, чтобы применить все изменения — это общий недостаток инкрементальных схем.
Veeam Backup позволяет сохранять резервные копии в течение любого времени по любой схеме (полные, инкрементальные, дифференциальные, синтетические), что позволяет выбрать ту, которая оптимально подходит и по ресурсам и по скорости восстановления в случае сбоя. Кроме того, Veeam Backup позволяет хранить резервные копии off-site, используя при передаче встроенный WAN-дедупликатор. DAG тоже возможно настроить в off-site, но там сравнительно больше технических трудностей (нужно настроить DNS, в off-site должен быть домен контроллер, сетевая задержка должна не превышать определенного значения).
P.S. Прощу прощения, если не правильно понял вопрос, так как понять можно было по разному.
Да, я так думаю («облако» — это больше про способ ведения бизнеса, а у технарей есть куча своих более старых и точных терминов для обозначения технологий).
Внутри компании модель «оплаты за ресурсы» имеет смысл, когда компания хочет вести подробный управленческий учет затрат — и тогда, скажем, разные отделы компании, которые пользуются внутренним ЦОД компании в разной степени, будут в конце месяца получать разные по размеру внутренние «счета» — никаких живых денег здесь платиться конечно не будет, однако в управленческом учете будут видны разные затраты этих отделов на ИТ (а это сводится, в конечном счете для компании, к затратам на оборудование, администрирование и электричество). И тогда, скажем, если речь идет про два цеха одного завода — то можно будет точнее рассчитать себестоимость продукции каждого такого цеха.
Честно говоря, я не нашел как Gartner определяет «Интернет технологии», но, учитывая типичную широту их определений, полагаю, что для них и протокол TCP/IP (даже применяемый только в Интрасети) — это тоже «Интернет технология».
Поэтому на мой взгляд, главное, в определении облака от Gartner — это те слова, которые я выделил курсивом — то есть ИТ ресурсы должны предоставляться:
1) Как сервис (здесь подразумевается гранулярный учет и оплата потребленных ИТ ресурсов — оплата по подписке, или «за операцию» и т.д.)
2) В требуемом заказчику масштабе
3) Гибко (этот термин у них раскрыт — это значит масштаб должен уметь меняться автоматически под нагрузкой)
Поэтому не любая виртуализация будет облаком, если в ней все три пункта не выполняются одновременно. На самом деле все три могут быть просто не нужны компании.
Gartner определяет "облачные вычисления" в широком смысле как «модель вычислений, в которой масштабируемые и гибкие ИТ-ресурсы предоставляются как сервис посредством Интернет-технологий». "Публичные облачные вычисления" определяются как облачные вычисления, предоставляемые внешнему заказчику. (Gartner IT Glossary).
мы задумали инструмент, который наладит работу службы поддержки и поможет компаниям и клиентам стать ближе. Рады сообщить, что он без пяти минут готов.
Ну пусть инструмент еще не готов, но замыслом-то инструмента можете поделиться? А то проблемы описаны верно, но какое решение вы можете предложить для их решения из статьи вообще не понятно.
1) Инициируется VMware снапшот. Диск переводится гипервизором в read-only режим. Все изменения на диске начинают записываться в «дельта-файл».
2) Начинается процесс копирования данных с диска в резервную копию (в общем случае) через сеть. Это не быстрый процесс. Все это время операции записи на исходный диск фактически производятся в дельта-файл.
3) После заверешения копирования данных, дается команда на удаление снапшота. При этом выполняется запись всех данных дельта-файла на сам диск, который был все это время в read only режиме. На время этого процесса как раз и происходит фриз — чем больше получился дельта-файл, тем более заметен фриз.
В случае же аппаратных снапшотов алгоритм работы другой:
1) Такой же: инициируется VMware снапшот. Диск переводится гипервизором в read-only режим. Все изменения на диске начинают записываться в «дельта-файл».
2) Инициируется аппаратный снапшот. А это, в отличие от п.2 в предыдущем варианте, быстрый процесс, так как он происходит локально на том же самом дисковом массиве с с оригинальными данными. На время этого процесса, все записи идут в дельта-файл. Дельта файл получается небольшим.
3) Снапшот VMware удаляется. Данные небольшого дельта-файла быстро записываются в основной диск. Дальнейшая работа по копированию данных идет уже с использованием аппаратного снапшота, и без участия виртуальной машины.
Из-за разницы в алгоритмах получается, что фриз во втором случае занимает гораздо меньше времени, чем в первом.
По п.2 — полагаю минимальный период создания аппаратного снапшота зависит от конкретной модели NAS, от параметров виртуальной машины, от состава приложений, которые в ней работают, и от интенсивности дисковых операций записи, которые они производят. Поэтому для каждой системы минимальный период создания снапшотов нужно определять опытным путем.
А вообще, перефразируя Евгения Чичваркина: «Техподдержка, если вы говорите, что клиент должен саппортить себя сам,- я заменю вас кнопкой» :)
У нас в форуме уже задавали такой вопрос: "Active Directory / iSCSI", и там есть хороший ответ, отражающий ситуацию «Yes, simple configurations – but better test it in your environment and share the results with the community :)»
Но, поскольку нужен именно freeware-вариант, то можно попробовать такой workaround: Google Диск имеет возможность офф-лайн синхронизации выбранных «облачных» папок на компьютер. При его инсталляции на компьютер задается локальная папка на диске, с которой Google Диск будет автоматически синхронизироваться. Вы можете указать в VEBF эту папку Google Диск в качестве пути сохранения резервных копий — и они будут автоматически синхронизироваться с облаком. (Скажу сразу, что этот вариант штатно не тестировался).
P.S. Прощу прощения, если не правильно понял вопрос, так как понять можно было по разному.
Кстати VMware в свое время целый продукт выпустила на эту тему: vCenter Chargeback Manager.
Поэтому на мой взгляд, главное, в определении облака от Gartner — это те слова, которые я выделил курсивом — то есть ИТ ресурсы должны предоставляться:
1) Как сервис (здесь подразумевается гранулярный учет и оплата потребленных ИТ ресурсов — оплата по подписке, или «за операцию» и т.д.)
2) В требуемом заказчику масштабе
3) Гибко (этот термин у них раскрыт — это значит масштаб должен уметь меняться автоматически под нагрузкой)
Поэтому не любая виртуализация будет облаком, если в ней все три пункта не выполняются одновременно. На самом деле все три могут быть просто не нужны компании.
Ну пусть инструмент еще не готов, но замыслом-то инструмента можете поделиться? А то проблемы описаны верно, но какое решение вы можете предложить для их решения из статьи вообще не понятно.