Недавно установил ваш продукт, все нравится, интерфейс хорош, бэкапит очень быстро.
Но есть несколько НО, которые портят картину:
Первое и самое главное: я не очень доверяю механизму forever increment. Что если по каким-то причинам increment копия окажется битой, а veeam этого не заметит? Это ведь будет означать, что восстановление полной копии уже никогда не будет выполнено корректно, так как больше full бэкапа никогда не будет. Может быть можно делать промежуточные full хотя бы из командной строки?
Мне очень понравился механизм отправки e-mail сообщений, классная штука! Но у меня на работе прокси, и функция оказалась бесполезной, она не работает.
Схема с одним заданием выглядит ну совсем несерьезной. Вы же планируете это потом допилить и всунуть во взрослый veeam, ну там то она уж точно понадобится! Пора уже реализовать.
Также у меня вопрос — можно ли организовать проведения бэкапа при выключении компьютера?
А в целом спасибо за хорошую и бесплатную программу!
А на чем зарабатывают такие компании? Я так понимаю, что разработка движка — дорогое удовольствие.
На пожертвования? Или оказывают какие-то услуги по интеграции движка в игру?
Странно видеть все это от технического человека, если честно.
Такими речами кормят нас постоянно, сколько я работаю в этой сфере, столько слышу подобное.
Ну подешевеет флеш, ну будут его использовать побольше, может даже не для совсем уж критичных задач. И что?
Причем тут docker и NetApp со своим флешом? Как они связаны? Если докер будет работать на Неттаповском флеше все станет с ног на голову?
Как облако (в нотации NetApp, конечно) будет уменьшать необходимость админов? Data Ontap в облаке нужно настраивать так же, как и не в облаке (да-да, диски менять не надо...)
Мои глаза(((
Вы вообще СХД видели что такое?
Сервер с примотанной скотчем полкой — это не СХД.
Резервирования контроллеров нет, RAID нет, поддержки нет (а это существенная часть расходов, если что), функционала толком нет. Покупать СХД если вам нужен сервер с дисками действительно не стОит, перед СХД стоЯт совсем другие задачи.
Может быть я скажу нехорошую вещь, но при подготовке к экзамену лучше использовать дампы. Причем не как список ответов, а как список вопросов. Качество дампов скверное, нужно прочитать все вопросы и найти самостоятельно ответы. Так вы и материал запомните и экзамен сдадите.
Дело все в том, что не зная вопросов, очень тяжело понять, что знать нужно, а что нет. Мне, к примеру, не приходило в голову, что меня могут спросить сколько именно символов в лицензионном ключе начиная с версии Data ONTAP 8.2. И таких вопросов, к сожалению, не мало.
Ну и, конечно, прочитать весь курс + большое количество Technical report по темам экзамена.
Ну не надо мерить так диски, ну что же это такое… То файлики копируют, то dd запускают.
Любой диск на обычном ПК будет значительно быстрее дискового массива с тысячью дисками за 2 млн $, если запускать на него 1 поток.
Никакое нормальное приложение никогда (надеюсь) не будет работать в таком однопоточном режиме с подобным профилем нагрузки. Сделайте один раз оценку, напишите профиль (а лучше несколько) на VDBench и используйте его для оценки производительности. Или найдите их в интернете.
Немного теории можно подчерпнуть в неплохой статье здесь
Я, в общем-то, согласен, я свою мысль вел к тому, что не нужно делать агрегат из 4 RAID групп следующего вида:
rg0 — 11disks
rg1 — 22disks
rg2 — 22disks
rg3 — 22disks,
так как что бы там не придумал NetApp в последних прошивках, такая конфигурация всегда будет тормозить.
Если же делать одну группу чуть меньше емкостью, но при этом сохранить кол-во дисков одинаковым, то это не должно сильно сказываться на производительности до момента полного заполнения емкости агрегата (что и так приведет к огромным проблемам производительности).
Спасибо за статью!
Тема новая и интересная, использовать ее не хочется, но иногда надо:))
В таком случае мы получим первую группу немного короче чем вторую, но это не проблема, так как в последних версиях ONTAP специально для этой цели оптимизировали механизм работы рейд груп, теперь допускается иметь достаточно большую разбежность рейдгрупп в одном агрегате.
Честно говоря я не знаю, что там сделали в последних версиях ONTAP на эту тему, но ведь чудес не бывает и разные RAID группы в агрегате обязательно будут приводить к различной производительности «частей» тома. Возможно они научились делать разные по длине страйпы, но производительность все равно будет страдать.
Интересно, насколько хорошо в действительности обстоит дело с поддержкой решений FlexPod. Поддержка вообще у всех вендоров отвратительная, а уж в случае стыков нескольких вендоров… не будет ли кейс мотаться между вендорами огромное время?
Данная процедура более чем стандартная, и описана в документации вендора (например, здесь)
Вообще говоря, такие операции как вывод узла из кластера нужно делать только тогда, когда 100% уверен в своих знаниях по этому вопросу и использовать только официальную документацию. А не так — прочитал хабр и пошел удалять ноды.
SAN LIF'ы можно не мигрировать
SAN LIF'ы не надо мигрировать в принципе. SAN полностью управляется мультипасингом, необходимо его проверить на всех хостах, использующих данный массив в качестве блочного таргета.
С другой стороны, ведь этот диск пока позиционируется для корпоративного сектора. А там RAID, spare, автоматический мониторинг состояния диска с предупреждающим копированием на spare, ну и «плавающая область» записи с запасными блоками.
Сколько работаю по специфике СХД с различными заказчиками — ни разу не встретился с тем, чтобы SSD диски массово начинали выходить из строя по причине окончания циклов перезаписи.
А еще с другой стороны — может это только я не встречался?=)
Потому что люди привыкли, что их данные хранятся на дисках. Если НЖМД=) совсем уйдут с рынка, то SSD тоже перестанут называть дисками. Просто сейчас переходный период в названиях.
Можно же просто купить дополнительную полку. У вас СХД на поддержке у вендора?
кладутся на эту СХД
К сожалению, несмотря на двухконтроллерность, иногда массивы оказываются недоступны совсем, полностью. И если нет поддержки у вендора — то надолго. В такой ситуации бывает нелишним отресториться куда-нибудь на другой носитель, любой, чтобы восстановить работу критичных сервисов.
Может получится рассказать это начальству и выбить хотя бы ленточку?
Но есть несколько НО, которые портят картину:
Также у меня вопрос — можно ли организовать проведения бэкапа при выключении компьютера?
А в целом спасибо за хорошую и бесплатную программу!
Возьмем общее число играющих людей. Более 50% этих людей играет и пользуется Windows, а не Linux.
Нет, утверждение там было что "те кто играет в игры, все же больше на Windows, чем на Linux."
Больше — значит более 50% от общего числа.
На пожертвования? Или оказывают какие-то услуги по интеграции движка в игру?
Такими речами кормят нас постоянно, сколько я работаю в этой сфере, столько слышу подобное.
Ну подешевеет флеш, ну будут его использовать побольше, может даже не для совсем уж критичных задач. И что?
Причем тут docker и NetApp со своим флешом? Как они связаны? Если докер будет работать на Неттаповском флеше все станет с ног на голову?
Как облако (в нотации NetApp, конечно) будет уменьшать необходимость админов? Data Ontap в облаке нужно настраивать так же, как и не в облаке (да-да, диски менять не надо...)
Вы вообще СХД видели что такое?
Сервер с примотанной скотчем полкой — это не СХД.
Резервирования контроллеров нет, RAID нет, поддержки нет (а это существенная часть расходов, если что), функционала толком нет. Покупать СХД если вам нужен сервер с дисками действительно не стОит, перед СХД стоЯт совсем другие задачи.
Да, с этим и связан, но смысл запоминания точного количества символов от меня ускользает. И таких вопросов немало
Дело все в том, что не зная вопросов, очень тяжело понять, что знать нужно, а что нет. Мне, к примеру, не приходило в голову, что меня могут спросить сколько именно символов в лицензионном ключе начиная с версии Data ONTAP 8.2. И таких вопросов, к сожалению, не мало.
Ну и, конечно, прочитать весь курс + большое количество Technical report по темам экзамена.
Любой диск на обычном ПК будет значительно быстрее дискового массива с тысячью дисками за 2 млн $, если запускать на него 1 поток.
Никакое нормальное приложение никогда (надеюсь) не будет работать в таком однопоточном режиме с подобным профилем нагрузки. Сделайте один раз оценку, напишите профиль (а лучше несколько) на VDBench и используйте его для оценки производительности. Или найдите их в интернете.
Немного теории можно подчерпнуть в неплохой статье здесь
rg0 — 11disks
rg1 — 22disks
rg2 — 22disks
rg3 — 22disks,
так как что бы там не придумал NetApp в последних прошивках, такая конфигурация всегда будет тормозить.
Если же делать одну группу чуть меньше емкостью, но при этом сохранить кол-во дисков одинаковым, то это не должно сильно сказываться на производительности до момента полного заполнения емкости агрегата (что и так приведет к огромным проблемам производительности).
Тема новая и интересная, использовать ее не хочется, но иногда надо:))
Честно говоря я не знаю, что там сделали в последних версиях ONTAP на эту тему, но ведь чудес не бывает и разные RAID группы в агрегате обязательно будут приводить к различной производительности «частей» тома. Возможно они научились делать разные по длине страйпы, но производительность все равно будет страдать.
NetApp вообще отличается некоторой сложностью внутренней архитектуры, особенно кластер.
Вообще говоря, такие операции как вывод узла из кластера нужно делать только тогда, когда 100% уверен в своих знаниях по этому вопросу и использовать только официальную документацию. А не так — прочитал хабр и пошел удалять ноды.
SAN LIF'ы не надо мигрировать в принципе. SAN полностью управляется мультипасингом, необходимо его проверить на всех хостах, использующих данный массив в качестве блочного таргета.
Сколько работаю по специфике СХД с различными заказчиками — ни разу не встретился с тем, чтобы SSD диски массово начинали выходить из строя по причине окончания циклов перезаписи.
А еще с другой стороны — может это только я не встречался?=)
Мне кажется, сейчас самое время для хорошей статьи, карму уже хватит сливать.
Можно же просто купить дополнительную полку. У вас СХД на поддержке у вендора?
К сожалению, несмотря на двухконтроллерность, иногда массивы оказываются недоступны совсем, полностью. И если нет поддержки у вендора — то надолго. В такой ситуации бывает нелишним отресториться куда-нибудь на другой носитель, любой, чтобы восстановить работу критичных сервисов.
Может получится рассказать это начальству и выбить хотя бы ленточку?