Привет, с вами снова Veeam Support! Сегодня в центре нашего внимания очень любопытный кейс: задание верификации SureBackup прекращается на середине создания снапшота, выдавая сообщение об ошибке общего характера: “The specified feature is not supported by this version.” (Данная функциональность не поддерживается в этой версии).
В задание верификации входило несколько виртуальных машин, но не удавалось обработать одну-единственную. Более того, задание верификации базировалось на задании резервного копирования, которое отрабатывало без каких-либо ошибок, выполняя бэкап и этой самой ВМ.
О нашем расследовании читайте под катом.
Вообще-то такие ошибки могут возникнуть в силу нескольких причин — например, есть ряд ограничений функциональности у бесплатного гипервизора Free ESXi (поэтому его мы не поддерживаем). Но здесь был не тот случай – гипервизор был явно не Free, все остальные машины прекрасно обрабатывались заданием SureBackup, да и проблемная машина нормально бэкапилась заданием резервного копирования.
Тем не менее, раз эта машина становилась камнем преткновения для задания SureBackup, имело смысл рассмотреть ее попристальней.
Первое, что бросилось в глаза – эта машина, назовем ее VM01, была значительно больше других по размеру: один из ее дисков был больше 2ТБ. Отметив этот факт, мы приступили к анализу журнала работы задания Veeam Backup & Replication. Вот что там обнаружилось:
Честно говоря, в тот момент записи в логах нам не очень помогли, но, по крайней мере, стало ясно, что генератором сообщения об ошибке является VMware vSphere API.
Тут мы, не мудрствуя лукаво, выполнили поисковый запрос, введя в нем строку исходного сообщения об ошибке:
В найденной записи фигурировало имя диска. Это оказался тот самый диск VMDK размером больше 2ТБ, который уже обратил на себя внимание. Также фигурирует тип диска – seSparse, то есть space-efficient sparse.
Тут мы вспомнили о том, что при создании снапшота диска размером более 2ТБ для дельта-диска VMware vSphere использует не VMFS (vmfssparse), а как раз-таки формат seSparse. Об этом написано в статье базы знаний VMware KB 2058287.
Наша проблема, вероятно, как-то связана с использованием диска типа seSparse для хранения дельты (redo log). Но что же конкретно явилось первопричиной? И тут мы обратили внимание еще на одну деталь: исходная ВМ и виртуальная лаборатория, задействованная в задании SureBackup, располагались на vSAN datastore.
Общеизвестно, что технология верификации SureBackup использует Veeam vPower NFS datastore для того, чтобы «поднять» с нее виртуальные машины, при этом дельты (redo logs) для машин в задании верификации редиректятся на основную datastore (в нашем случае это vSAN):
То есть образовалась такая система хранения, в которой основные диски располагались на NFS datastore, а дельты (redo logs) – на vSAN. Но поскольку для всех машин, кроме проблемной VM01, такая система работала нормально, мы пришли к выводу, что нужно исследовать вопрос совместимости seSparse и vSAN.
Расследование привело нас к документу о VMware vSAN, где говорится: “Virtual SAN does not support SE Sparse disks.” — виртуальная SAN не поддерживает диски SE Sparse.
Документ, однако, относился к версии vSphere v5.5, а в нашем случае была vSphere 6.0. Мы связались с коллегами из VMware, которые подтвердили, что указанное ограничение имеет место и для версии 6.0, и для версии 6.5.
Наконец-то все куски паззла были собраны воедино, и вот итог: невозможна такая конфигурация систем хранения, где основной диск находился бы на NFS/VMFS, а файл дельты (redo log) seSparse на vSAN — ибо, как сказано в документации VMware, снапшот наследует тип VMFS_type.
Внимательный читатель задаст резонный вопрос: а почему для больших дисков (более 2ТБ) нормально отрабатывало резервное копирование? Ведь seSparse не поддерживается vSAN? Ответ прост: при создании снапшота ВМ, чей основной диск расположен на vSAN, VMware использует для сохранения дельты тип снапшота VSANSPARSE.
Примечание: Подробно о VSANSPARSE можно почитать в статье VMware (скачиваемый PDF).
Админу на заметку:
Мы посоветовали пользователю перенести «песочницу» (virtual lab) на datastore без использования vSAN. В этом случае при редиректе тип снапшота меняться не будет.
Подобные проблемы могут возникать при работе с ВМ на vSAN, если попытаться запустить мгновенное восстановление Instant recovery для машин с дисками большого размера (> 2TБ). Отметим, что приведенное решение применимо и здесь, поскольку тоже выполняется редирект снапшота.
Дальнейшие исследования вопроса показали, что в некоторых случаях проблема проявляется и при работе в режиме hot-add (virtual appliance). В любом варианте нужно внимательно проанализировать, какие datastores и какие типы снапшотов будут задействованы при той или иной операции. Ну а если все-таки остались вопросы – мы всегда готовы помочь.
В преддверии зимних каникул Veeam снова дарит подарки: мы разыгрываем 6 путевок на конференции VeeamON 2018, которые в новом году пройдут в разных регионах мира. Путевка включает в себя билет в обе сторны, проживание в комфортабельном отделе недалеко от места проведения конференции, и, разумеется, посещение всех мероприятий конференции (включая те, для которых потребуется бронирование места).
Все, что вам нужно сделать для участия в розыгрыше – это зарегистрироваться здесь.
Если же вы читаете нас, будучи, например, в Австралии или в Канаде, то можно открыть страницу нужной региональной конференции, ссылки на них здесь.
Регистрация закроется 31 декабря 2017, так что лучше поторопиться.
Имена шести счастливчиков будут объявлены уже в новом, 2018 году. За новостями можно следить на нашей страничке в FB, а также в твиттере.
В задание верификации входило несколько виртуальных машин, но не удавалось обработать одну-единственную. Более того, задание верификации базировалось на задании резервного копирования, которое отрабатывало без каких-либо ошибок, выполняя бэкап и этой самой ВМ.
О нашем расследовании читайте под катом.
В фокусе
Вообще-то такие ошибки могут возникнуть в силу нескольких причин — например, есть ряд ограничений функциональности у бесплатного гипервизора Free ESXi (поэтому его мы не поддерживаем). Но здесь был не тот случай – гипервизор был явно не Free, все остальные машины прекрасно обрабатывались заданием SureBackup, да и проблемная машина нормально бэкапилась заданием резервного копирования.
Тем не менее, раз эта машина становилась камнем преткновения для задания SureBackup, имело смысл рассмотреть ее попристальней.
Первое, что бросилось в глаза – эта машина, назовем ее VM01, была значительно больше других по размеру: один из ее дисков был больше 2ТБ. Отметив этот факт, мы приступили к анализу журнала работы задания Veeam Backup & Replication. Вот что там обнаружилось:
Честно говоря, в тот момент записи в логах нам не очень помогли, но, по крайней мере, стало ясно, что генератором сообщения об ошибке является VMware vSphere API.
Анализируем журналы VMware
Тут мы, не мудрствуя лукаво, выполнили поисковый запрос, введя в нем строку исходного сообщения об ошибке:
В найденной записи фигурировало имя диска. Это оказался тот самый диск VMDK размером больше 2ТБ, который уже обратил на себя внимание. Также фигурирует тип диска – seSparse, то есть space-efficient sparse.
Тут мы вспомнили о том, что при создании снапшота диска размером более 2ТБ для дельта-диска VMware vSphere использует не VMFS (vmfssparse), а как раз-таки формат seSparse. Об этом написано в статье базы знаний VMware KB 2058287.
Наша проблема, вероятно, как-то связана с использованием диска типа seSparse для хранения дельты (redo log). Но что же конкретно явилось первопричиной? И тут мы обратили внимание еще на одну деталь: исходная ВМ и виртуальная лаборатория, задействованная в задании SureBackup, располагались на vSAN datastore.
Общеизвестно, что технология верификации SureBackup использует Veeam vPower NFS datastore для того, чтобы «поднять» с нее виртуальные машины, при этом дельты (redo logs) для машин в задании верификации редиректятся на основную datastore (в нашем случае это vSAN):
То есть образовалась такая система хранения, в которой основные диски располагались на NFS datastore, а дельты (redo logs) – на vSAN. Но поскольку для всех машин, кроме проблемной VM01, такая система работала нормально, мы пришли к выводу, что нужно исследовать вопрос совместимости seSparse и vSAN.
Расследование привело нас к документу о VMware vSAN, где говорится: “Virtual SAN does not support SE Sparse disks.” — виртуальная SAN не поддерживает диски SE Sparse.
Документ, однако, относился к версии vSphere v5.5, а в нашем случае была vSphere 6.0. Мы связались с коллегами из VMware, которые подтвердили, что указанное ограничение имеет место и для версии 6.0, и для версии 6.5.
Наконец-то все куски паззла были собраны воедино, и вот итог: невозможна такая конфигурация систем хранения, где основной диск находился бы на NFS/VMFS, а файл дельты (redo log) seSparse на vSAN — ибо, как сказано в документации VMware, снапшот наследует тип VMFS_type.
Внимательный читатель задаст резонный вопрос: а почему для больших дисков (более 2ТБ) нормально отрабатывало резервное копирование? Ведь seSparse не поддерживается vSAN? Ответ прост: при создании снапшота ВМ, чей основной диск расположен на vSAN, VMware использует для сохранения дельты тип снапшота VSANSPARSE.
Примечание: Подробно о VSANSPARSE можно почитать в статье VMware (скачиваемый PDF).
Админу на заметку:
- Снапшоты типа VSANSPARSE создаются на дисках vSAN.
- Снапшоты типа VMFS_sparse или seSparse создаются на обычных дисках VMFS, при этом имеет значение размер диска и версия VMFS (так, снапшоты на VMFS6 всегда будут иметь тип seSparse вне зависимости от размера).
- В случае редиректа на другую datastore тип диска снапшота будет наследоваться от родительского диска.
Предлагаем решение
Мы посоветовали пользователю перенести «песочницу» (virtual lab) на datastore без использования vSAN. В этом случае при редиректе тип снапшота меняться не будет.
Подобные проблемы могут возникать при работе с ВМ на vSAN, если попытаться запустить мгновенное восстановление Instant recovery для машин с дисками большого размера (> 2TБ). Отметим, что приведенное решение применимо и здесь, поскольку тоже выполняется редирект снапшота.
Дальнейшие исследования вопроса показали, что в некоторых случаях проблема проявляется и при работе в режиме hot-add (virtual appliance). В любом варианте нужно внимательно проанализировать, какие datastores и какие типы снапшотов будут задействованы при той или иной операции. Ну а если все-таки остались вопросы – мы всегда готовы помочь.
Помимо полезного, вот еще и приятное
В преддверии зимних каникул Veeam снова дарит подарки: мы разыгрываем 6 путевок на конференции VeeamON 2018, которые в новом году пройдут в разных регионах мира. Путевка включает в себя билет в обе сторны, проживание в комфортабельном отделе недалеко от места проведения конференции, и, разумеется, посещение всех мероприятий конференции (включая те, для которых потребуется бронирование места).
Все, что вам нужно сделать для участия в розыгрыше – это зарегистрироваться здесь.
Если же вы читаете нас, будучи, например, в Австралии или в Канаде, то можно открыть страницу нужной региональной конференции, ссылки на них здесь.
Регистрация закроется 31 декабря 2017, так что лучше поторопиться.
Имена шести счастливчиков будут объявлены уже в новом, 2018 году. За новостями можно следить на нашей страничке в FB, а также в твиттере.
mikkisse
Спасибо. Как всегда очень интересно. Пишите почаще :)
polarowl Автор
Спасибо за ваше внимание к нашим продуктам и блогу. Постараемся продолжить серию в наступающем году.)