Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
SQL бесплатен для использования в составе продуктов MS System Center, т.е. для DPM не требуется покупать доп. лицензии да БД.
Следующий продукт, который безусловно понравился — это Veeam. Он очень удобен и его зеленый цвет безусловно радует серый админский интерфейс, но цена для организации ошеломляющая (у нас кластер на 6 двухпроцессорных лезвиях). Мы его протестировали и были бы готовы использовать при наличии денег. Но увы.
В бесплатной версии всего два ограничения, емнип:
1. Нет инкрементных бэкапов
2. Невозможно создать расписание из GUI
Первое ограничение для вас не так уж и важно, если по итогу вы все равно делаете полные бэкапы для всех машин. А второе можно обойти использованием Powershell-скриптов, т.к. у Veeam есть Powershell API.
А вообще по статье очень сложно понять общую схему бэкапа. Например, непонятно, куда что бэкапится. Такое ощущение, что все лежит на одном хранилище и только раз в месяц уходит на ленты.
Поэтому сложно что-то покритковать или чему-то научиться.
А так — могу посоветовать пристальнее присмотреться к встроенному Windows Backup в WS2012. Например, с его помощью можно делать инкрементальные бэкапы на отдельное хранилище по iscsi. Для бэкапа больших файл-серверов работает просто отлично и люто экономит место плюс можно без проблем восстанавливать отдельные объекты ФС.
Да, собственно, для бэкапа почти любых серверов работает хорошо — к примеру, можно без остановки делать application-consistent бэкапы серверов БД и Exchange.
Более того, бэкапы можно делать не только, запуская WB из гостевой машины, но и из хоста тоже, и даже остается возможность инкрементальных бэкапов. Правда, насколько я знаю, консистентные бэкапы серверов БД так уже не сделать.
Из минусов — полное восстановление сервера из бэкапа может быть весьма медленным и, в некоторых случаях, небеспроблемным.
Позволю себе несколько замечаний.
1.
Это не так, после отработки отказа виртуальные машины будут в состоянии как после hard reset. И отработает она не мгновенно, а через несколько минут.
2. Снапшоты для бекапов не предназначены.
3. По гигабиту должно копироваться около 400 Гб в час (120 МБ/с * 60 * 60 / 1024), т.е. в 10 раз быстрее, чем у вас. При этом Windows Backup сервера exchange у нас отдаёт по 100 гигабайт в час примерно, что тоже не 400, но там большую часть времени занимает «подготовка».
На всякий случай Windows Server 2012 умеет агрегировать каналы, поэтому можно легко сделать 2 гигабита.
4. Динамические диски вроде как не рекомендуют использовать в продакшне
По возможности рекомендую бекапить всё-таки рабочие нагрузки, а не виртуальные машины. SQL server прекрасно умеет это делать самостоятельно, домен-контроллеры и exchange — средствами windows backup. Многие продукты имеют встроенные механизмы бекапа. Скрипту остаётся лишь забрать бекапы и куда-нибудь сложить для хранения.
1.
«сгорит» один из хостов, то виртуальные машины продолжат работать практически без паузы — сработает миграция («главное чтобы она сработала») — все продолжит работать
Это не так, после отработки отказа виртуальные машины будут в состоянии как после hard reset. И отработает она не мгновенно, а через несколько минут.
2. Снапшоты для бекапов не предназначены.
3. По гигабиту должно копироваться около 400 Гб в час (120 МБ/с * 60 * 60 / 1024), т.е. в 10 раз быстрее, чем у вас. При этом Windows Backup сервера exchange у нас отдаёт по 100 гигабайт в час примерно, что тоже не 400, но там большую часть времени занимает «подготовка».
На всякий случай Windows Server 2012 умеет агрегировать каналы, поэтому можно легко сделать 2 гигабита.
4. Динамические диски вроде как не рекомендуют использовать в продакшне
По возможности рекомендую бекапить всё-таки рабочие нагрузки, а не виртуальные машины. SQL server прекрасно умеет это делать самостоятельно, домен-контроллеры и exchange — средствами windows backup. Многие продукты имеют встроенные механизмы бекапа. Скрипту остаётся лишь забрать бекапы и куда-нибудь сложить для хранения.
1. hard reset — долго думал, термин из области мобильных устройств :)
4. насколько я помню, для vhdx эту тему отменили и теперь можно, не рекомендуется использовать динамическую память
4. насколько я помню, для vhdx эту тему отменили и теперь можно, не рекомендуется использовать динамическую память
По гигабиту должно копироваться около 400 Гб в час (120 МБ/с * 60 * 60 / 1024), т.е. в 10 раз быстрее, чем у вас.
копировать можно с такой скоростью, а экспортировать виртуальную машину нет — выходит намного медленнее: эскпорт происходит по сети в расшаренную папку. Даже интересно можно ли ускорить этот процесс?
Конфигурация полки
PDs for VD 0:
# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
— DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace
— 0 — - — - RAID60 Optl N 29.107 TB dflt N N none N
============
Basics:
======
Controller = 0
Model = LSI MegaRAID SAS 9261-8i
— EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp
— 252:0 0 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:1 1 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:2 2 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:3 3 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:4 4 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:5 5 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:6 6 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:7 7 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 30T 15T 15T 50% /mnt/lun
ethtool enp4s0f1
Settings for enp4s0f1:
Supported ports: [ FIBRE ]
Supported link modes: 10000baseT/Full
# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
— DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace
— 0 — - — - RAID60 Optl N 29.107 TB dflt N N none N
============
Basics:
======
Controller = 0
Model = LSI MegaRAID SAS 9261-8i
— EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp
— 252:0 0 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:1 1 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:2 2 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:3 3 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:4 4 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:5 5 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:6 6 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
252:7 7 Onln 0 7.276 TB SATA HDD N N 512B ST8000AS0002-1NA17Z U
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 30T 15T 15T 50% /mnt/lun
ethtool enp4s0f1
Settings for enp4s0f1:
Supported ports: [ FIBRE ]
Supported link modes: 10000baseT/Full
1,5 тбайт виртуалок с 3 гипервизоров esxi 5.5 сливается в ночь за 3 часа.
К esxi серверам прицеплена полка как NFS шара по 10гигабитам.
По поводу HYPER-V и малой скорости, попробуй не шару, а по iscsi зацепиться к хранилищу и замерь скорость в итоге.
ЗЫ. Перешел в свое время с Hyper-V На vmware из-за того что можно пробрасывать USB ключи и миграцию наживую виртуалок между хостами.
Чем лучше бекапа изнутри средствами Windows Backup?
Простите, я не смог удержаться :)
Ниже вполне здоровая критика и направления куда копать.
| В общем, магия, сглаз, или же просто мелкософт
В темные века природные явления были магией и результатом деятельности богов, а болезни результатом сглаза. С тех времен человечество выросло и разобралось в причине и следствиях многих вещей.
Так и у вас, вы не можете объяснить причину, поэтому по дефолту виноват микрософт, а на кривизну собственных рук никто внимания обращать не хочет. Частое явление :)
| экономит бюджет посредством AVMA-активации — неограниченная активация виртуальных машин 2012 R2 DATA CENTER внутри хоста;
только если двухсокетный хост может держать более 14 гостевых систем начинается профит от покупки редакции Data Center
| удаление всех снепшотов у виртуальных машин
не используйте снапшоты сами по себе
| за счет снепшотов виртуальная машина может значительно прибавить в размере
совсем не обязательно, больше проблем может вызвать время консолидации и проседание производительности хранилища в этот момент
| применение динамических жестких дисков для тех виртуальных машин, где не нужна быстрая скорость работы диска
фиксированный размер жестких дисков нужен только для разделов с базами данных, в остальных случаях вполне позволительно использовать динамически расширяемые диски. а для файлохранилищ еще и включить дедупликацию на разделе
| 2-ой раз самый эпичный исход, который только можно было ожидать — DPM убил сам себя!
прощальную записку с признанием оставил? или вы сделали настройки и нажали кнопки не до конца понимая, что то делаете на так?
| Выяснилось что id машины, которую восстанавливали совпал с id машины sql-server
[/facepalm], но рад, что вы быстро усвоили урок, и не на продакшене.
| MS SQL-Server Standart,
[grammar nazi]
D. Все англицкие «стандарт» заканчиваются на D. SQL Server Standard
[/grammar nazi]
| DPM [bla bla bla] бекапы хранит на динамическом диске
DPMу презентуется хранилище (к примеру локальный диск без файловой системы), а там он уже сам нарезает динамические разделы, и могу сказать, что их там могут быть сотни на одном диске.
| то есть повреждается база и всё… Все бекапы потеряны
тсс, парень, базу DPM тоже можно бэкапить
| Не понятно почему не использовать статический диск, который можно было подключать куда угодно с легкостью, нежели динамический.
обычная фобия. пройдет с годами :) да и SAS диски куда угодно тоже не подключишь
| Я выбрал скрипт потому как не надо сервера баз данных. Все что нужно это табличка «что, когда бекапиться» и логи для отладки. И, собственно, это бесплатно и это саморазвитие.
у вас много свободного времени, когда его не станет, такой самопал исчезнет.
| а скрипт позволяет делать копию только всей виртуальной машины
эм. диск виртуальной машины Hyper-V можно подключить виртуальным жестким диском в любой винде начиная с вин7 через powershell, или через диспетчер управления дисками
| построение экспортируемой копии по сети дело долгое для Hyper-V — примерно 40 Гб в час на гигабитной сетке
а нет ли у вас затыка на датасторе или в сети? у меня даже банальный экспорт с хоста полностью утилизирует гигабитный интерфейс, это порядка 350 гигабайт в час
|xcopy F:\DATA H:\BackUP /H /Y /C /R /E
переходите уже на robocopy, если сильно хочется копировать встроенными средствами
| Сеть Control отделена физически
вы либо не знакомы с парктикой использования VLAN, либо у вас нет управляемого сетевого оборудования, что вполне объясняет проблемы с скоростью копирования по сети
| проблемы в сети предприятия, например кольца
ага. нет управляемого сетевого оборудования
| выделены LUN-ы — по 250 Гб для операционки, 20 Гб кворум и 6 Тб — хранилище виртуальных машин.
нарезая кучу мелких лунов вы убиваете производительность схд. надеюсь вы не отдали под маленькеи луны ссд накопители? %)
| Supermicro с двумя процессорами и 196 Гб [bla bla bla] На нем поднята роль Hyper-V и на него осуществляется экспорт виртуальных машин
в Windows Server 2012 R2 Hyper-V есть host-2-host миграция. зачем вы делаете экспорт, если можете настроить миграцию между хостами и сократить время возможного простоя до десятков секунд?
| Также некоторые машины можно бекапить «на горячую»,
да они все должны бэкапиться на горячую.
Ниже вполне здоровая критика и направления куда копать.
| В общем, магия, сглаз, или же просто мелкософт
В темные века природные явления были магией и результатом деятельности богов, а болезни результатом сглаза. С тех времен человечество выросло и разобралось в причине и следствиях многих вещей.
Так и у вас, вы не можете объяснить причину, поэтому по дефолту виноват микрософт, а на кривизну собственных рук никто внимания обращать не хочет. Частое явление :)
| экономит бюджет посредством AVMA-активации — неограниченная активация виртуальных машин 2012 R2 DATA CENTER внутри хоста;
только если двухсокетный хост может держать более 14 гостевых систем начинается профит от покупки редакции Data Center
| удаление всех снепшотов у виртуальных машин
не используйте снапшоты сами по себе
| за счет снепшотов виртуальная машина может значительно прибавить в размере
совсем не обязательно, больше проблем может вызвать время консолидации и проседание производительности хранилища в этот момент
| применение динамических жестких дисков для тех виртуальных машин, где не нужна быстрая скорость работы диска
фиксированный размер жестких дисков нужен только для разделов с базами данных, в остальных случаях вполне позволительно использовать динамически расширяемые диски. а для файлохранилищ еще и включить дедупликацию на разделе
| 2-ой раз самый эпичный исход, который только можно было ожидать — DPM убил сам себя!
прощальную записку с признанием оставил? или вы сделали настройки и нажали кнопки не до конца понимая, что то делаете на так?
| Выяснилось что id машины, которую восстанавливали совпал с id машины sql-server
[/facepalm], но рад, что вы быстро усвоили урок, и не на продакшене.
| MS SQL-Server Standart,
[grammar nazi]
D. Все англицкие «стандарт» заканчиваются на D. SQL Server Standard
[/grammar nazi]
| DPM [bla bla bla] бекапы хранит на динамическом диске
DPMу презентуется хранилище (к примеру локальный диск без файловой системы), а там он уже сам нарезает динамические разделы, и могу сказать, что их там могут быть сотни на одном диске.
| то есть повреждается база и всё… Все бекапы потеряны
тсс, парень, базу DPM тоже можно бэкапить
| Не понятно почему не использовать статический диск, который можно было подключать куда угодно с легкостью, нежели динамический.
обычная фобия. пройдет с годами :) да и SAS диски куда угодно тоже не подключишь
| Я выбрал скрипт потому как не надо сервера баз данных. Все что нужно это табличка «что, когда бекапиться» и логи для отладки. И, собственно, это бесплатно и это саморазвитие.
у вас много свободного времени, когда его не станет, такой самопал исчезнет.
| а скрипт позволяет делать копию только всей виртуальной машины
эм. диск виртуальной машины Hyper-V можно подключить виртуальным жестким диском в любой винде начиная с вин7 через powershell, или через диспетчер управления дисками
| построение экспортируемой копии по сети дело долгое для Hyper-V — примерно 40 Гб в час на гигабитной сетке
а нет ли у вас затыка на датасторе или в сети? у меня даже банальный экспорт с хоста полностью утилизирует гигабитный интерфейс, это порядка 350 гигабайт в час
|xcopy F:\DATA H:\BackUP /H /Y /C /R /E
переходите уже на robocopy, если сильно хочется копировать встроенными средствами
| Сеть Control отделена физически
вы либо не знакомы с парктикой использования VLAN, либо у вас нет управляемого сетевого оборудования, что вполне объясняет проблемы с скоростью копирования по сети
| проблемы в сети предприятия, например кольца
ага. нет управляемого сетевого оборудования
| выделены LUN-ы — по 250 Гб для операционки, 20 Гб кворум и 6 Тб — хранилище виртуальных машин.
нарезая кучу мелких лунов вы убиваете производительность схд. надеюсь вы не отдали под маленькеи луны ссд накопители? %)
| Supermicro с двумя процессорами и 196 Гб [bla bla bla] На нем поднята роль Hyper-V и на него осуществляется экспорт виртуальных машин
в Windows Server 2012 R2 Hyper-V есть host-2-host миграция. зачем вы делаете экспорт, если можете настроить миграцию между хостами и сократить время возможного простоя до десятков секунд?
| Также некоторые машины можно бекапить «на горячую»,
да они все должны бэкапиться на горячую.
для файлохранилищ еще и включить дедупликацию на разделе
Вот, кстати, очень дельный совет. Рекомендую всем опробовать. У меня на нескольких терабайтах видео (нет, не того самого, а рекламных роликов и блоков) дедупликация сэкономила 47% объема раздела. И, т.к. это оффлайновая дедупликация, требования к ресурсам совершенно приемлемые. Опять же, можно настраивать расписание.
Еще до появления на Хабре компании Veeam нашел на Codeplex утилиту «HV Backup» — не требует остановки виртуальных машин, сразу пакует в zip-архивы. На powershell написал небольшую обертку для вызова и отправки отчета на почту. Так с тех пор и пользуюсь.
Ссылки
- hypervbackup.codeplex.com
- github.com/nelsh/HVbackupLaunch — в качестве примера для создания своего отчета
немного поясню конфигурацию, описанную в статье.
во-первых, есть две сети физически разделенные — сеть предприятия и сеть control. кластер построен на основе шасси fujitsu bx900s2 с блейдами bx924s3-s4, в нем же (в шасси) стоят 2 свитча — 10G свитч и 1G свитч. 10g свитч подсоеинен к сети предприятия через 10 гигабитную циску, а 1g свитч воткнут в сеть control в 1гигабитный hp свитч. то есть не нужны никакие виланы. все разделено отдельным оборудованием — это дороже, это проще, и это надежней. таким образом у блейдов активны 2 сетевые карты, на основе которых сделано 2 hyper-v коммутатора, 10g используется только виртуальными машинами, 1g только хостами. также в сети control есть сервер бекапов hyper-v reserv — на него с помощью скрипта экспортируются виртуальные машины, и если виртуальная машина на кластере сдохла можно либо скопировать с hyper-v rezerv, либо восстановить на нем по месту если необходимо срочно.
во-вторых, ваши расчеты верны на счет скорости копирования, но насчет экспорта у меня выходит намного медленней, если я копирую по сети — то да почти весь гигабитный канал задействован, но ежели экспортирую виртуалку по сети то 40-60 гиг в час.
во-первых, есть две сети физически разделенные — сеть предприятия и сеть control. кластер построен на основе шасси fujitsu bx900s2 с блейдами bx924s3-s4, в нем же (в шасси) стоят 2 свитча — 10G свитч и 1G свитч. 10g свитч подсоеинен к сети предприятия через 10 гигабитную циску, а 1g свитч воткнут в сеть control в 1гигабитный hp свитч. то есть не нужны никакие виланы. все разделено отдельным оборудованием — это дороже, это проще, и это надежней. таким образом у блейдов активны 2 сетевые карты, на основе которых сделано 2 hyper-v коммутатора, 10g используется только виртуальными машинами, 1g только хостами. также в сети control есть сервер бекапов hyper-v reserv — на него с помощью скрипта экспортируются виртуальные машины, и если виртуальная машина на кластере сдохла можно либо скопировать с hyper-v rezerv, либо восстановить на нем по месту если необходимо срочно.
во-вторых, ваши расчеты верны на счет скорости копирования, но насчет экспорта у меня выходит намного медленней, если я копирую по сети — то да почти весь гигабитный канал задействован, но ежели экспортирую виртуалку по сети то 40-60 гиг в час.
по поводу экспорта по сети — провел эксперимент — подсоединил напрямую гигабитным патчкордом к хосту hyper-v сетевое хранилище — подключил iscsi-диск — копирование 112 Мбайт\сек, экспорт виртуальной машины 150 Мбит/сек… ведать дело все-таки в hyper-v. и наверное будет правильнее и быстрее экспортировать сначала на локальный диск, а потом копировать на сетевое хранилище.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система бекапов виртуальных машин или как сэкономить деньги организации