Комментарии 29
НЛО прилетело и опубликовало эту надпись здесь
Например что? Агент проект живой и туда постоянно добавляются новые фичи.
Например, поддержка хостов KVM/oVirt/RHEV?
Отличное предложение (без шуток), но полноценная поддержка любой системы виртуализации проект по своим масштабам на порядок больший, чем скромный агент бекапящий ОС.
Как вы понимаете, разработчики не могут просто так взять и начать пилить фичи которые им кажутся интереснее. Есть план разработки построенный аналитиками, в том числе, и на основе количества запросов от пользователей на реализацию той или иной фукнции. Если буквально завтра все начнут просить поддержку KVM, вероятно будет странно не добавить её в ближайшем релизе. С другой стороны, если какой-то функции всё нет и нет, вероятно и запросов на неё практически нет. Такая вот правда рынка…
Как вы понимаете, разработчики не могут просто так взять и начать пилить фичи которые им кажутся интереснее. Есть план разработки построенный аналитиками, в том числе, и на основе количества запросов от пользователей на реализацию той или иной фукнции. Если буквально завтра все начнут просить поддержку KVM, вероятно будет странно не добавить её в ближайшем релизе. С другой стороны, если какой-то функции всё нет и нет, вероятно и запросов на неё практически нет. Такая вот правда рынка…
разработчики не могут просто так взять
Вот это-то мы как раз очень хорошо понимаем, потому что «просто так» Veeam ничего не делает.
Хотя нет, можно просто так поднять цены на продление техподдержки, это факт. Можно вместо продукта продавать «подписку». Можно сделать уровень техподдержки по минимальному из всех приобретенных продуктов, чтобы никому в голову не приходило использовать Standard, там, где достаточно Standard.
Поэтому понимание, что разработку мы, разумеется, оплатим — есть. Такова правда рынка.
Всё верно, вот только к разработчикам это не имеет никакого отношения. Наше дело код писать, а продают его отдельные, специально обученные люди. И, вероятно, неплохо это делают, раз компании уже 12 лет.
Делают неплохо и разработчики, и продажники. Но совершенно честно скажу, что три основных момента, упомянутых выше, просто заставляют искать альтернативы, насколько бы не были талантливы разработчики.
Но мне, как клиенту, издалека видится что ниша-то свободна. Волна «импортозамещения», которое по факту в лучшем случае заканчивается переходом на СПО, и пустующая ниша гипервизорного KVM бекапа.
В то же время мне понятно, что с одной стороны рынок России маленький, а с другой стороны, что новый гипервизор, это возможно абсолютно новый продукт с соответствующими издержками.
Но мне, как клиенту, издалека видится что ниша-то свободна. Волна «импортозамещения», которое по факту в лучшем случае заканчивается переходом на СПО, и пустующая ниша гипервизорного KVM бекапа.
В то же время мне понятно, что с одной стороны рынок России маленький, а с другой стороны, что новый гипервизор, это возможно абсолютно новый продукт с соответствующими издержками.
А если предположить, что эта ниша настолько мала, что распыляться на неё нет никакого смысла от слова совсем и затраты на её освоение будут в разы больше даже самых позитивных прогнозов на прибыль?
Лично мне видитися, что такие узкие ниши отличная почва для стартаперов. Конкурентов или совсем нет, или они в зачаточном состоянии, mvp можно запилить по быстренькому минимальным количеством людей с околонулевыми расходами и дальше по ситуации. Может окажется, что ваша аудитория это студенческие лабы и денег на этом рынке нет. А может выяснится, что ваша ниша испытывает взрывной рост и через месяц вы миллионер.
Лично мне видитися, что такие узкие ниши отличная почва для стартаперов. Конкурентов или совсем нет, или они в зачаточном состоянии, mvp можно запилить по быстренькому минимальным количеством людей с околонулевыми расходами и дальше по ситуации. Может окажется, что ваша аудитория это студенческие лабы и денег на этом рынке нет. А может выяснится, что ваша ниша испытывает взрывной рост и через месяц вы миллионер.
НЛО прилетело и опубликовало эту надпись здесь
Как предлагаете сравнивать? Количество строчек в релиз нотах так себе вариант.
Вот, например, была добавлена поддержка BTRFS, которой на Windows нет. Функция запрашиваемая многими, а всего одна строчка в релизе. С другой стороны, на расширение функционала Windows агента приходит намного больше запросов (что не и не удивительно), а дальше чистая система приоритетов.
Агент для Linux проект молодой и требует более тщательного подхода в разработке из-за особенностей платформы. У него есть своя полноценная ветка на нашем форуме где любой желающий может написать свои предложения по развитию. Форум постоянно мониторится и написанное там учитвывается. Инфа 146% =)
Вот, например, была добавлена поддержка BTRFS, которой на Windows нет. Функция запрашиваемая многими, а всего одна строчка в релизе. С другой стороны, на расширение функционала Windows агента приходит намного больше запросов (что не и не удивительно), а дальше чистая система приоритетов.
Агент для Linux проект молодой и требует более тщательного подхода в разработке из-за особенностей платформы. У него есть своя полноценная ветка на нашем форуме где любой желающий может написать свои предложения по развитию. Форум постоянно мониторится и написанное там учитвывается. Инфа 146% =)
Я могу тут только одну очевидную проблему назвать — поддержка свежих версий дистрибутивов откровенно хромает. Когда нельзя обновить Redhat 7.5 до 7.6 на протяжении трёх месяцев из-за veeam — это крайне неприятно. И с прошлыми апгрейдами такая же была ситуация.
Код модуля открыт и лежит на гите. Если сможете адаптировать быстрее, вам все скажут большое спасибо.
Если более по делу: святая обязанность создателей всех дистрибутивов линукса, это в каждом релизе изменить уйму существующих функций, отключить десяток не нужных(по их мнению), придумать пачку новых и не написать никакой документации по этому поводу. Во всяком случае так устроен мир по их версии.
Однако в реалиях настоящего мира, когда надо обеспечивать совместимость со старыми версиями с оглядкой на особенности каждого дистрибутива + не забывать добавлять новые фичи, даже просто понять что-же изменилось в новой версии дистра, занимает далеко не нулевое время. А потом вечный круг разработка-тестирование.
Так что обеспечить поддержку последний версий RHEL мы хотим не меньше вашего, однако причины…
Если более по делу: святая обязанность создателей всех дистрибутивов линукса, это в каждом релизе изменить уйму существующих функций, отключить десяток не нужных(по их мнению), придумать пачку новых и не написать никакой документации по этому поводу. Во всяком случае так устроен мир по их версии.
Однако в реалиях настоящего мира, когда надо обеспечивать совместимость со старыми версиями с оглядкой на особенности каждого дистрибутива + не забывать добавлять новые фичи, даже просто понять что-же изменилось в новой версии дистра, занимает далеко не нулевое время. А потом вечный круг разработка-тестирование.
Так что обеспечить поддержку последний версий RHEL мы хотим не меньше вашего, однако причины…
Сможете рассказать, что критичного изменилось в ядре 4.14 из 7.6 по сравнению с 4.14 из 7.5, что потребовалось три месяца? Причём дело только в ядре, обновление прочих пакетов никак не затронуло veeam. По гиту этого не отследить — практика одного большого патча не способствует чтению изменений. Если верить документации редхата, ничего, что влияет на агент, не было. access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/7.6_release_notes/index#new_features_kernel
Да, новая версия и новые функции — это хорошо. Но работающая текущая версия с минимальным обновлением для совместимости — важнее для пользователя со сломавшимся бэкапом.
Да, новая версия и новые функции — это хорошо. Но работающая текущая версия с минимальным обновлением для совместимости — важнее для пользователя со сломавшимся бэкапом.
Конечно согласен, что изменений между версиями 7.5 и 7.6 было мало. Более того, модуль, собранный под 7.5 оказался совместим с 7.6. Кажется, что проблем нет.
Однако хочу напомнить, может кто не в курсе, у нас была колоссальная проблема при релизе 7.5, когда модуль, собранный для ядра 7.0 был kABI совместим с обновлённым, успешно загружался и гарантированно ронял серваки. Обычно пользователи не любят, когда их серваки падают.
В результате, было принято решение не пытаться работать на ядрах будущих релизов EL7, которые не прошли через наш QA.
Кроме того, шли работы по подготовке к релизу VBR 9.5, VAL 3.0 и VAW 3.0. Выделить ресурсы на hot fix для поддержки rhel 7.6 — а это несколько дней регресса — было сложно.
Да, согласен, что возможно мы недостаточно уделили внимание релизу 7.6. Выводы из этой ситуации мы сделали.
Но для нас всё же приоритетом является надёжность работы серверов наших пользователей.
Однако хочу напомнить, может кто не в курсе, у нас была колоссальная проблема при релизе 7.5, когда модуль, собранный для ядра 7.0 был kABI совместим с обновлённым, успешно загружался и гарантированно ронял серваки. Обычно пользователи не любят, когда их серваки падают.
В результате, было принято решение не пытаться работать на ядрах будущих релизов EL7, которые не прошли через наш QA.
Кроме того, шли работы по подготовке к релизу VBR 9.5, VAL 3.0 и VAW 3.0. Выделить ресурсы на hot fix для поддержки rhel 7.6 — а это несколько дней регресса — было сложно.
Да, согласен, что возможно мы недостаточно уделили внимание релизу 7.6. Выводы из этой ситуации мы сделали.
Но для нас всё же приоритетом является надёжность работы серверов наших пользователей.
В такой ситуации, если точно известно, что на новых ядрах модуль работать не должен, правильнее указать в зависимостях модуля максимальную версию ядра, равную текущей. Тогда при обновлении человек будет видеть, что у него есть проблема с зависимостями и будет ожидать, что могут быть проблемы с бэкапом, либо с версией ядра. Это уже частично решило бы проблему для клиентов, обновляющих систему своевременно.
Наверное да. Я подумаю об этом.
Тем не менее, недавний случай с ошибкой в ядре, которая прилетела с патчем в 2.6.32-754.6.3 (была починена в следующем) напоминает о том, что с обновлениями надо быть осторожным.
Как минимум не стоит делать обновления автоматически и для всей инфраструктуры сразу.
Ещё хочу заметить, что идея kABI совместимых модулей не очень соответствует идеям ядра Linux.
Dkms модуль ядра практически не вызывает проблем. Конечно он может не собраться из-за специфичного патча или из-за очередного обновления ядра. Но серваки пачками не кладёт. Если есть возможность использовать dkms модуль, я бы советовал использовать именно его.
Скажите, почему у вас есть коммандлет Set-VBRJobAdvancedBackupOptions, но нету соттветствующего Get-* — иногда приходится перепроверять настройки десятков заданий и это геморно.
Настройки задания РК — Storage — Advanced — Integration — Limit processed per storage snapsho to == какая польза от этой фичи? Мне, например, интереснее такая схема — в задании на закладке Virtual Mashines выбраны датасторы (LUN-ы) с ВМ (к примеру на каждом датасторе по 15 ВМ), тот самый лимит, например 10, берет 10 ВМ с первого датастора, делает им снапшот (потом снапшот луна...) и бэкапит их, далее берет следующие 10 ВМ (5 с первого датастора и 5 со второго) и так далее. А сейчас у вас получается, что делается снапшет 10 ВМ на каждом датасторе (шторм снапшотов по всем лунам задания), а уже следующим этапом пяти ВМ. В общем, интересно чтобы ВМ бэкапились по очереди, как без storage snapshots.
Настройки задания РК — Storage — Advanced — Integration — Limit processed per storage snapsho to == какая польза от этой фичи? Мне, например, интереснее такая схема — в задании на закладке Virtual Mashines выбраны датасторы (LUN-ы) с ВМ (к примеру на каждом датасторе по 15 ВМ), тот самый лимит, например 10, берет 10 ВМ с первого датастора, делает им снапшот (потом снапшот луна...) и бэкапит их, далее берет следующие 10 ВМ (5 с первого датастора и 5 со второго) и так далее. А сейчас у вас получается, что делается снапшет 10 ВМ на каждом датасторе (шторм снапшотов по всем лунам задания), а уже следующим этапом пяти ВМ. В общем, интересно чтобы ВМ бэкапились по очереди, как без storage snapshots.
Польза от этой фичи ровна такая, как вы и описали (если я правильно понял посыл): ограничивать количество машин с варными снепшотами перед созданием storage snapshot. Меньше нагрузка, быстрее создаётся снепшот, быстрее бекап.
Но тут главная часть заключена в per storage snapshot т.е. это не отмена параллельной обработки.
Если стоит задача бекапить поочереди с разных датастор, то лучшее решение это разнести их по джобам. В каждую джобу добавить датастору, а не отдельные машины и включить последовательный запуск джоб (на шаге Scheduler выбрать After this job).
Про командлет постараюсь узнать.
Но тут главная часть заключена в per storage snapshot т.е. это не отмена параллельной обработки.
Если стоит задача бекапить поочереди с разных датастор, то лучшее решение это разнести их по джобам. В каждую джобу добавить датастору, а не отдельные машины и включить последовательный запуск джоб (на шаге Scheduler выбрать After this job).
Про командлет постараюсь узнать.
вот вы говорите, что нету запросов про командлет get, но кто в таком исполнении использует «Limit processed per storage snapsho to»? приходится делать делать задания на каждый лун отдельно и шедулить After this job (хотя вы же сами не рекомендуете так шедулить).
А если я скажу, что вы первый, кто обратился с запросом такого сценария?
Фичи появляются не по нашей прихоти, а исходя из запросов клиентов. Было много запросов на такое исполнение — мы сделали, будут запросы схожие с вашим — тоже сделаем.
Фичи появляются не по нашей прихоти, а исходя из запросов клиентов. Было много запросов на такое исполнение — мы сделали, будут запросы схожие с вашим — тоже сделаем.
где и как можно оформить запрос?
Можно в личном кабинете создать тикет в тп с пометкой Предложение новой фичи. Они уточнят детали и перешлют проджектам.
Можно написать на форуме. Я бы даже сказал, что это более предпочтительный вариант т.к. там имеются большие шансы получить прямой фидбек.
Можно написать на форуме. Я бы даже сказал, что это более предпочтительный вариант т.к. там имеются большие шансы получить прямой фидбек.
Про Get.
Его не делали из-за отсутствия запросов на него. Звучит странно, но большинство работает с опциями напрямую, без сторонних кмдлетов.
Получить такие настройки для всех джоб достаточно легко:
Его не делали из-за отсутствия запросов на него. Звучит странно, но большинство работает с опциями напрямую, без сторонних кмдлетов.
$Job.Options.etc.Получить такие настройки для всех джоб достаточно легко:
$Job.Options.BackupTargetOptions.
Однако маленькое уточнение теперь в новой версии о ESX(i)4.1 можно забыть:
VMware infrastructure
Platforms
vSphere 6.x
vSphere 5.x
Hosts
ESXi 6.x
ESXi 5.x
VMware infrastructure
Platforms
vSphere 6.x
vSphere 5.x
Hosts
ESXi 6.x
ESXi 5.x
Кстати-кстати, не допилили ли вы агент на предмет нормального резервного копирования Exchange? Логами, а не бинарными образами?
Поставил Update 4.
Обрадовался бесплатным лицензиям на 6 агентов, сэкономим три лицензии на серверную физику, неплохо!
Так и не обнаружил возможность задать разное расписание для full и incremental. Это поразительно, честно говоря.
Обрадовался бесплатным лицензиям на 6 агентов, сэкономим три лицензии на серверную физику, неплохо!
Так и не обнаружил возможность задать разное расписание для full и incremental. Это поразительно, честно говоря.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор обновления Veeam Backup & Replication 9.5 Update 4