Как стать автором
Обновить

Комментарии 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 — долго думал, термин из области мобильных устройств :)
4. насколько я помню, для vhdx эту тему отменили и теперь можно, не рекомендуется использовать динамическую память
А как ещё назвать reset по кнопке? :)
Про динамическую память, пожалуй, попрошу пруфов. Потому что у меня прямо противоположная информация, если в гайде к приложению явно не указано, что динамическую память использовать нельзя (например Exchange)
А как ещё назвать reset по кнопке?

На IBM PC-совместимых компьютерах с древности прижились термины «cold reboot» и «warm reboot».

P.S — Но, случайно заглянув в русскоязычную версию этой статьи, увидел термины «hard reboot», «soft reboot».
Ощутил себя динозавром.
По гигабиту должно копироваться около 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



1,5 тбайт виртуалок с 3 гипервизоров esxi 5.5 сливается в ночь за 3 часа.
К esxi серверам прицеплена полка как NFS шара по 10гигабитам.

По поводу HYPER-V и малой скорости, попробуй не шару, а по iscsi зацепиться к хранилищу и замерь скорость в итоге.

ЗЫ. Перешел в свое время с Hyper-V На vmware из-за того что можно пробрасывать USB ключи и миграцию наживую виртуалок между хостами.
Ну, миграция наживую есть и в HyperV (пока все хосты живы — мигрирует, а в случае падения гипервизора — да, резетится на другом гипервизоре)

А с USB — да, беда.
когда переходил, не было миграции, но тогда главный был вопрос USB ключи для 1ски, программными нет возможности обойтись изза «особенной» редакции
А что мешало вставить HASP-ключи в любой физический комп в локалке и раздать их «по сети»?
Ключи не клиентские.
Чем лучше бекапа изнутри средствами 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 миграция. зачем вы делаете экспорт, если можете настроить миграцию между хостами и сократить время возможного простоя до десятков секунд?

| Также некоторые машины можно бекапить «на горячую»,
да они все должны бэкапиться на горячую.
для файлохранилищ еще и включить дедупликацию на разделе

Вот, кстати, очень дельный совет. Рекомендую всем опробовать. У меня на нескольких терабайтах видео (нет, не того самого, а рекламных роликов и блоков) дедупликация сэкономила 47% объема раздела. И, т.к. это оффлайновая дедупликация, требования к ресурсам совершенно приемлемые. Опять же, можно настраивать расписание.
Еще до появления на Хабре компании Veeam нашел на Codeplex утилиту «HV Backup» — не требует остановки виртуальных машин, сразу пакует в zip-архивы. На powershell написал небольшую обертку для вызова и отправки отчета на почту. Так с тех пор и пользуюсь.

Ссылки



немного поясню конфигурацию, описанную в статье.
во-первых, есть две сети физически разделенные — сеть предприятия и сеть 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. и наверное будет правильнее и быстрее экспортировать сначала на локальный диск, а потом копировать на сетевое хранилище.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории