По поводу транспорта: Direct SAN Access поддерживается — как раз в компоненте Agent for VMware (Windows). Это один из стандартных транспортов предоставляемых vStorage API, так что проблем с ним не должно быть — достаточно подключить LUN от виртуального хранилища (датастора) к виндовой машине с агентом и этот транспорт будет использован автоматически. Приоритет транспортов, если доступны одновременно несколько, следующий: Direct SAN access->HotAdd->NBD
Поясню, что имелось в виду касаемого агентного/безагентного подхода на примере VMware. Может быть 3 разных подхода к установке решения резервного копирования:
1) Все компоненты внутрь Windows ВМ на том же гипервизоре. Судя по всему, вам был выбран именно этот подход — поэтому именно его я подробнее рассмотрю ниже.
2) Все компоненты на отдельную физическую или виртуальную машину вне гипервизора
3) Сервер управления на отдельной машине + агент (в случае Вима это будет «backup proxy») на отдельной машине
В 1ом случае (реализуется и Вимом и Акронисом) и сервер управления и агент для VMware стоят рядом. При этом остальные ВМ с данного гипервизора бэкапятся в режиме либо HotAdd (через аттач их дисков к основной ВМ), либо NBD (Network Block Device = чтение по сети). Режимы открытия виртуальных дисков определяются VMware vStorage API, которое является основным и используется всеми вендорами в том числе Nakivo, Veeam, Acronis, Veritas, и т.д. (есть исключения в виде Zerto, но это всё-таки исключения).
Агентом в данной терминологии я называю компонент, который рядом с собой тянет библиотеки от vStorage API от VMware и отвечает за чтение исходных данных с ВМ + за передачу этих данных в хранилище резервных копий.
Соответственно, в случае Veeam, вы устанавливаете продукт на эту Windows VM и получаете и сервер управления и агент («Backup proxy») использующий vStorage API. В случае Acronis можно так же поставить сервер управления (Acronis Management Server) + агента для VMware который в том числе доступен в виндовом варианте. Поэтому в обоих случаях подход к установке идентичен. Разница только в том, что с Вимом «агент» ставится всегда по умолчанию, т.к. этот продукт заточен именно под виртуальные среды, а в случае Акронис эту опцию (компонент Agent for VMware (Windows)) нужно явно выбрать.
Все вышесказанное, естественно, не подразумевает установку агентов внутрь бэкапящихся ВМ, т.е. речь исключительно про «agent-less» подход.
Для application-aware резервных копий установка агентов внутрь ВМ также не нужна (в Acronis Backup 11.7 это было не так) — сбор метаданных приложений осуществляется следующим образом:
С помощью API предоставляемого VMware Tools (VIX API) внутрь ВМ забрасываются скрипты, которые отвечают за сбор метаданных приложений + за очистку журнала логов транзакций. Передача собранных метаданных происходит в направлении гипервизор->агент для VMware, т.е. наличие сетевого канала между гостевой ОСью ВМ и агентом не требуется. После сбора информации о приложении резервное копирование осуществляется обычным способом через vStorage API.
Разные вендоры по разному осуществляют данную операцию — кто-то опционально требует установку дополнительных «мини-агентов», которые стоят постоянно установлены, другие предпочитают закидывать нужные скрипты налету через VMware Tools (VIX канал). Главное, что во всех этих случаях канал связи между этими мини-агентами и основным агентом для VMware не зависит от сети гостевой ОСи ВМ, которую бэкапят, а осуществляется через тот же сетевой канал, который используется основным агентом для связи с гипервизором (по сути — это соединение с VMkernel интерфейсом ESXi хоста).
TL;DR: Суть сводится к тому, что принципиальных отличий в первоначальной настройке и дальнейшем сопровождении (с точки зрения настройки сетевой инфраструктуры) любых решений резервного копирования для VMware быть не должно. Таким образом разница между решениями состоит в основном в наличии или отсутствии конкретных «фич» (например Instant Restore, гранулярное восстановление данных конкретных приложений, репликация ВМ, и т.д.), но не в принципиальном подходе.
Припоминаю что в том числе были проблемы с созданием снапшотов (возможно, quiesce, не уверен) и, как я упоминал, они были рандомные — то делались, то нет. Почему-то когда команду на создание снапшота отправляла вим прокси, таких проблем я не наблюдал.
Здесь разница в поведении скорее всего от того, что Вим по умолчанию использует не-quiesced снапшоты (чтобы их включить, нужно явно выставить соответствующую опцию), что и приводит к тому, что они всегда успешны на стороне гипервизора. В Acronis Backup по умолчанию создаются application-consistent (quiesced) снапшоты, чтобы гарантировать консистентность данных внутри резервной копии ВМ, но, как показывает практика, с quiesced снапшотами у VMware всегда были (и остаются) проблемы, отсюда и плохое впечатление от работы Acronis Backup, который зависит от этой функциональности VMware.
Начиная с 12.5 версии мы сделали автоматическое переключение на не-quiesced снапшоты, если quiescing не удался за 3 попытки, чтобы сгладить данный эффект, и при этом сделать всё возможное для гарантии консистентности данных.
А общее впечатление конкретно портит весь этот архитектурный карнавал с агентами, для висферы мне потребовался vApp с, кажется, слесом на борту и развернутым там агентом.
Агент для VMware предоставляется в двух вариантах — под Windows (что по сути является полным аналогом Backup Proxy от Вим), либо в виде легковесного vApp (Virtual Appliance). «Виндовый» агент может быть установлен вместе с сервером управления и в итоге получится вим-like установка, где всё стоит на одной машине. Т.е. использовать vApp в принципе не обязательно. Здесь, судя по всему, у вас возникли проблемы с первоначальной настройкой, т.к. разворачивание Virtual Appliance действительно не самая явная операция, а наличие опции Agent for VMware (Windows Agent) не явно видно при изначальной установке.
А отсутствие вменяемого аналога quick rollback (откат только изменившихся блоков) вообще убил. Уверен, у многих большая часть операций восстановления — это суть откат к определенной точке, а не восстановление целой машины из-за неконсистентности VMFS или разрушения массива. И вот эта функция мне недоступна.
Опции по инкрементальному восстановлению ВМ действительно не было в версии Acronis Backup 11.7, но начиная с 12ой (которая была выпущена год назад), она доступна и по умолчанию включена, т.е. применяется при любом восстановлении в «оригинальную» или «существующую» машину.
Это я все к тому, что такая агрессивная и глупая маркетинговая чушь отталкивает более-менее образованных инженеров или руководителей, особенно, когда видишь когда здесь «новинки» и «эксклюзивно» это то, что было у Veeam 7 лет назад (мнение касательно маркетинга не только мое, но и многих моих коллег).
За отзыв по маркетинговым материалам отдельное спасибо — будем улучшать. По поводу Instant Restore — из нового (того о чем материалы умолчали) в 12.5 есть действительно уникальная технология "финализации" смонтированных машин, которая позволяет даже при отсутствии «storage vMotion» лицензии (либо на отдельностоящих ESXi хостах без vCenter-а), в фоновом режиме копировать машины смонтированные из образа в основной датастор, без необходимости выключать машину.
Большинство моих коллег не желает использовать Акронис в первую очередь из-за того, что архитектура решения агентная.
Можете пояснить в чем основная сложность с агентной архитектурой? На данный момент любое решение для более чем одной среды (например нескольких гипервизоров + физических машин) по сути является агентным. Если взять тот же Вим, то и там используется подобное решение с наличием Backup proxy компонента, который есть ни что иное как агент, которые позволяет расширять инфраструктуру когда одного дефолтного «агента» недостаточно.
Подозреваю, что основное впечатление у вас осталось от негативного опыта первоначальной настройки и необходимости в принципе устанавливать какие-либо дополнительные агенты или проблемы начались уже после этого?
По поводу опыта работы с Acronis можете, пожалуйста, написать мне в личном сообщении (или прямо здесь), какие конкретно были проблемы при использовании?
Мне, как одному из сотрудников Acronis, очень хочется разобраться, что же именно пошло не так. Если остались какие-нибудь логи, или хотя бы примеры ошибок (мб было обращение в тех. поддержку?) — буду благодарен за любую информацию.
С тезисом «кухарка не может управлять гос-вом» вполне согласен, но в данном топике обсуждается тема, в которой компетенции комментаторов как минимум не ниже чем компетенции тех, кто эти законы принимает, поэтому в данном случае возмущение комментаторов вполне справедливо. На мой взгляд главные грехи наших законотворцев это дилетантство и некомпетентность. То, что мы наблюдаем с законами яровых, законе о мессенджерах, законе о деанонимизиации — это и есть квинтессенция этих грехов.
В моём идеальном мире (немного помечтаем) решения, которые глобально влияют на жизнь общества (любой его более менее значимой части >0.01%), принимаются исключительно людьми, которые обладают экспертизой по этим решениям. На эту тему есть хорошая книга «Мигрант, или Brevi finietur» (фантастика Дяченко), где в обществе каждому его представителю присваивается «индекс социальной ответственности», т.е. некий статус, который позволяет ему принимать те или иные решения в определенных областях и вес его голоса зависит от этого статуса. Таким образом решения принимаются исключительно людьми, обладающими компетенциями по конкретным вопросам.
В случае регулирования интернета и IT сферы в целом сейчас явно наблюдается перекос в сторону, когда именно «кухарки» с низким уровнем социальной ответственности лезут в серверную и указывают сисдаминам как им жить — это то и бесит :)
Много писанины свысока и критики собеседника, при этом практического смысла в словах буквально 0. У меня аж «бомбануло» от такой демагогии и поэтому, по Вашему определению, я заведомо неправ, но всё-таки рискну ответить в вашем же стиле: «Критикуешь — предлагай». Вот ваш оппонент высказал своё _конкретное_ предложение по изменению судебной системы, пусть и не лишенное недостатков. От вас же ничего кроме «это всё чушь и компот» и «Вы очевидно очень молоды и совершенно не знаете жизни.» по существу не было сказано.
Если я «правильно» понял (спишем это на случайный несистематичный проблеск разума), вы считаете, что ситуация такова, что т.к. сути принимаемых законов плебс не понимает (просто определению в понятиях «пастух-стадо»), то не может судить о великих задумках наших законотворцев, а уж высказывать своё мнение по этим вопросам — это вообще за гранью разумного! Удобная позиция «пусть за меня всё решают эксперты, и кто я такой чтобы им указывать», но если она применима к врачебной практике (да и то не всегда), это не значит, что её можно пихать во все остальные аспекты жизни.
Глобальных изменений в алгоритмы дедупликации относительно версии 11.7 не вносилось. Реализация поддержки дедупликации принципиально осталась той же самой. Улучшения производительности при восстановлении из дедуплицированных хранилищ планируется в будущих обновлениях.
Перед тем как что-то советовать нужно смотреть предметно, что произошло (посмотреть репорты со всех проблемных систем). Пожалуйста, дайте номер своей заявки, чтобы мы могли посмотреть и продолжить разбирательство.
P.S. Мог бы посоветовать мануальный апгрэйд с помощью специальной утилиты: https://kb.acronis.com/content/57721, но опять же нужно сначала понять текущее состояние
Еще небольшое уточнение: планы не появятся в ГУИ до тех пор, пока соответствующие агенты не будут обновлены, т.е. причиной 1ой проблемы является 2ая, но к сожалению из описания непонятно, что значит, что нельзя обновить агентов из веб интерфейса — соответствующая опция там присутствует.
Мы получили буквально несколько подобных жалоб на пропавшие планы (внутренний номер бага: TTASK-19069) и сейчас находимся в процессе исследования причин неудачной миграции планов с 11.7 на 12.5. Это не общая проблема, а специфичная для каждого конкретного случая, причем скорее всего планы можно будет вернуть, т.к. в базе Acronis Management Server они остались. Пожалуйста, дайте номер своей заявки в нашу службу поддержки, чтобы мы убедились, что проблема именно та, которую я описал выше.
Спасибо за пояснения. Соответствующий алерт про истечение свободного места планируется в будущих обновлениях (внутренний ID задачи: ABR-105473).
Однако, во 2-ом случае проблема случилась, похоже, не из-за недостатка места, а по другим причинам — в них нужно отдельно разбираться с помощью нашей службы поддержки.
В явном виде такого нет. Можете, пожалуйста, уточнить как именно вы видите поведение такой фичи? Т.е. какие ожидаются проверки (до, после, во время бэкапа?) и какое поведение процесса резервного копирования должно быть при обнаружении такой ситуации? Нам важно понять ожидания, чтобы правильно спроектировать поведение в будущем.
P.S. Свободное место в хранилище резервных копий отслеживается соответствующими динамически обновляемыми «виджетами» на «дашборде» + есть «алерт», но возможности выполнения определенных действий по истечению свободного места нет.
Ваш комментарий относится к продукту для домашних пользователей — Acronis True Image и мы проанализировали предыдущую историю обращений по Вашему аккаунту — дело там довольно запутанное. Наша служба поддержки свяжется с Вами в ближайшее время для разрешения всех возникших вопросов.
Да, там действительно есть исключения, если AMS установлен на линуксе, либо если нужно установить Agent for Linux — для этих случаев опция удаленной установки из веб консоли недоступна. В этом случае либо Ctrl+Shift+click, либо регистрировать во время установки агента (адрес AMS можно явно указать при установке агента).
Добавить уже установленный агент можно и просто по кнопке «Add». Если в диалоге добавления указать адрес+креды от машины где уже стоит агент, то после соединения он будет определен и его можно будет добавить (без переустановки). Метод через Ctrl+Shift+click был изначально предназначен только для внутреннего тестирования.
Настроек именно адаптивной производительности на данный момент нет (но планируется в будущем). Есть стандартные возможности ограничивать скорость записи в архив и/или приоритет процессов бэкапа на стороне агента.
Да, возможно автоматическое (in-place) обновление и плавный переход, так называемый side-by-side upgrade, при котором сначала считывается конфигурация из 11.7, а затем импортируется в 12.5, при этом сохраняя предыдущую инфраструктуру. Подробнее про оба режима можно почитать в этой статье: https://kb.acronis.com/content/59801 (пока что только на английском).
При обновлении сервера управления (AMS) до 12.5, старые агенты продолжат выполнять свои задачи по заданному расписанию, но будут видны как «недоступные» в консоли 12.5, до тех пор пока их тоже не обновят. Т.е. новые задачи на старые агенты будет нельзя назначать, как и изменять текущие задачи, но работать они будут.
Еще раз спасибо за разъяснения и отзывы — было продуктивно и нам в любом случае стало яснее над чем работать/что улучшать дальше.
1) Все компоненты внутрь Windows ВМ на том же гипервизоре. Судя по всему, вам был выбран именно этот подход — поэтому именно его я подробнее рассмотрю ниже.
2) Все компоненты на отдельную физическую или виртуальную машину вне гипервизора
3) Сервер управления на отдельной машине + агент (в случае Вима это будет «backup proxy») на отдельной машине
В 1ом случае (реализуется и Вимом и Акронисом) и сервер управления и агент для VMware стоят рядом. При этом остальные ВМ с данного гипервизора бэкапятся в режиме либо HotAdd (через аттач их дисков к основной ВМ), либо NBD (Network Block Device = чтение по сети). Режимы открытия виртуальных дисков определяются VMware vStorage API, которое является основным и используется всеми вендорами в том числе Nakivo, Veeam, Acronis, Veritas, и т.д. (есть исключения в виде Zerto, но это всё-таки исключения).
Агентом в данной терминологии я называю компонент, который рядом с собой тянет библиотеки от vStorage API от VMware и отвечает за чтение исходных данных с ВМ + за передачу этих данных в хранилище резервных копий.
Соответственно, в случае Veeam, вы устанавливаете продукт на эту Windows VM и получаете и сервер управления и агент («Backup proxy») использующий vStorage API. В случае Acronis можно так же поставить сервер управления (Acronis Management Server) + агента для VMware который в том числе доступен в виндовом варианте. Поэтому в обоих случаях подход к установке идентичен. Разница только в том, что с Вимом «агент» ставится всегда по умолчанию, т.к. этот продукт заточен именно под виртуальные среды, а в случае Акронис эту опцию (компонент Agent for VMware (Windows)) нужно явно выбрать.
Все вышесказанное, естественно, не подразумевает установку агентов внутрь бэкапящихся ВМ, т.е. речь исключительно про «agent-less» подход.
Для application-aware резервных копий установка агентов внутрь ВМ также не нужна (в Acronis Backup 11.7 это было не так) — сбор метаданных приложений осуществляется следующим образом:
С помощью API предоставляемого VMware Tools (VIX API) внутрь ВМ забрасываются скрипты, которые отвечают за сбор метаданных приложений + за очистку журнала логов транзакций. Передача собранных метаданных происходит в направлении гипервизор->агент для VMware, т.е. наличие сетевого канала между гостевой ОСью ВМ и агентом не требуется. После сбора информации о приложении резервное копирование осуществляется обычным способом через vStorage API.
Разные вендоры по разному осуществляют данную операцию — кто-то опционально требует установку дополнительных «мини-агентов», которые стоят постоянно установлены, другие предпочитают закидывать нужные скрипты налету через VMware Tools (VIX канал). Главное, что во всех этих случаях канал связи между этими мини-агентами и основным агентом для VMware не зависит от сети гостевой ОСи ВМ, которую бэкапят, а осуществляется через тот же сетевой канал, который используется основным агентом для связи с гипервизором (по сути — это соединение с VMkernel интерфейсом ESXi хоста).
TL;DR: Суть сводится к тому, что принципиальных отличий в первоначальной настройке и дальнейшем сопровождении (с точки зрения настройки сетевой инфраструктуры) любых решений резервного копирования для VMware быть не должно. Таким образом разница между решениями состоит в основном в наличии или отсутствии конкретных «фич» (например Instant Restore, гранулярное восстановление данных конкретных приложений, репликация ВМ, и т.д.), но не в принципиальном подходе.
Здесь разница в поведении скорее всего от того, что Вим по умолчанию использует не-quiesced снапшоты (чтобы их включить, нужно явно выставить соответствующую опцию), что и приводит к тому, что они всегда успешны на стороне гипервизора. В Acronis Backup по умолчанию создаются application-consistent (quiesced) снапшоты, чтобы гарантировать консистентность данных внутри резервной копии ВМ, но, как показывает практика, с quiesced снапшотами у VMware всегда были (и остаются) проблемы, отсюда и плохое впечатление от работы Acronis Backup, который зависит от этой функциональности VMware.
Начиная с 12.5 версии мы сделали автоматическое переключение на не-quiesced снапшоты, если quiescing не удался за 3 попытки, чтобы сгладить данный эффект, и при этом сделать всё возможное для гарантии консистентности данных.
Агент для VMware предоставляется в двух вариантах — под Windows (что по сути является полным аналогом Backup Proxy от Вим), либо в виде легковесного vApp (Virtual Appliance). «Виндовый» агент может быть установлен вместе с сервером управления и в итоге получится вим-like установка, где всё стоит на одной машине. Т.е. использовать vApp в принципе не обязательно. Здесь, судя по всему, у вас возникли проблемы с первоначальной настройкой, т.к. разворачивание Virtual Appliance действительно не самая явная операция, а наличие опции Agent for VMware (Windows Agent) не явно видно при изначальной установке.
Опции по инкрементальному восстановлению ВМ действительно не было в версии Acronis Backup 11.7, но начиная с 12ой (которая была выпущена год назад), она доступна и по умолчанию включена, т.е. применяется при любом восстановлении в «оригинальную» или «существующую» машину.
За отзыв по маркетинговым материалам отдельное спасибо — будем улучшать. По поводу Instant Restore — из нового (того о чем материалы умолчали) в 12.5 есть действительно уникальная технология "финализации" смонтированных машин, которая позволяет даже при отсутствии «storage vMotion» лицензии (либо на отдельностоящих ESXi хостах без vCenter-а), в фоновом режиме копировать машины смонтированные из образа в основной датастор, без необходимости выключать машину.
Можете пояснить в чем основная сложность с агентной архитектурой? На данный момент любое решение для более чем одной среды (например нескольких гипервизоров + физических машин) по сути является агентным. Если взять тот же Вим, то и там используется подобное решение с наличием Backup proxy компонента, который есть ни что иное как агент, которые позволяет расширять инфраструктуру когда одного дефолтного «агента» недостаточно.
Подозреваю, что основное впечатление у вас осталось от негативного опыта первоначальной настройки и необходимости в принципе устанавливать какие-либо дополнительные агенты или проблемы начались уже после этого?
Мне, как одному из сотрудников Acronis, очень хочется разобраться, что же именно пошло не так. Если остались какие-нибудь логи, или хотя бы примеры ошибок (мб было обращение в тех. поддержку?) — буду благодарен за любую информацию.
В моём идеальном мире (немного помечтаем) решения, которые глобально влияют на жизнь общества (любой его более менее значимой части >0.01%), принимаются исключительно людьми, которые обладают экспертизой по этим решениям. На эту тему есть хорошая книга «Мигрант, или Brevi finietur» (фантастика Дяченко), где в обществе каждому его представителю присваивается «индекс социальной ответственности», т.е. некий статус, который позволяет ему принимать те или иные решения в определенных областях и вес его голоса зависит от этого статуса. Таким образом решения принимаются исключительно людьми, обладающими компетенциями по конкретным вопросам.
В случае регулирования интернета и IT сферы в целом сейчас явно наблюдается перекос в сторону, когда именно «кухарки» с низким уровнем социальной ответственности лезут в серверную и указывают сисдаминам как им жить — это то и бесит :)
Если я «правильно» понял (спишем это на случайный несистематичный проблеск разума), вы считаете, что ситуация такова, что т.к. сути принимаемых законов плебс не понимает (просто определению в понятиях «пастух-стадо»), то не может судить о великих задумках наших законотворцев, а уж высказывать своё мнение по этим вопросам — это вообще за гранью разумного! Удобная позиция «пусть за меня всё решают эксперты, и кто я такой чтобы им указывать», но если она применима к врачебной практике (да и то не всегда), это не значит, что её можно пихать во все остальные аспекты жизни.
P.S. Мог бы посоветовать мануальный апгрэйд с помощью специальной утилиты: https://kb.acronis.com/content/57721, но опять же нужно сначала понять текущее состояние
Однако, во 2-ом случае проблема случилась, похоже, не из-за недостатка места, а по другим причинам — в них нужно отдельно разбираться с помощью нашей службы поддержки.
P.S. Свободное место в хранилище резервных копий отслеживается соответствующими динамически обновляемыми «виджетами» на «дашборде» + есть «алерт», но возможности выполнения определенных действий по истечению свободного места нет.
При обновлении сервера управления (AMS) до 12.5, старые агенты продолжат выполнять свои задачи по заданному расписанию, но будут видны как «недоступные» в консоли 12.5, до тех пор пока их тоже не обновят. Т.е. новые задачи на старые агенты будет нельзя назначать, как и изменять текущие задачи, но работать они будут.