Друг купил машину на замену своей лошади. Впечатления самые негативные. Пытался засыпать овёс в бак — он размок и забил бензонасос. Пришлось чинить. Попытался поставить в стойло — не влезает, пришлось перестраивать всю конюшню, да и асфальт класть до нее.
Чтобы ветер обдувал лицо надо опускать все стекла, причем дует только сбоку, лобовое не опускается. Поменял обратно на лошадь и слава Богу!
По теме:
Аппаратная не для того, чтобы разговаривать. Если вы хотите увеличить плотность компоновки, очевидно, что придется подводить туда больше питания и охлаждения. Как вы хотели иначе? Просто думать об этом надо до проекта, а не после.
Дмитрий, большое спасибо за статью! В свое время потратил много времени, чтобы все это собрать в своей голове, другим людям теперь можно просто отправлять эту статью=)
Вообще это относится ко всем вашим статьям про NetApp, спасибо за ваш труд!
Прошло 5 лет, а ваш вопрос остался без ответа=) Обидно.
Не знаю, актуально ли еще, но напишу:
Вы ошиблись дважды. Если у вас задержка 1мс, то вы успеете 1000 IOPS получить, а не 1. Но это произойдет только в том случае, если у вас IOPS следуют друг за другом и каждый следующий ждет подтверждения предыдущего. Если бы приложения работали именно так, то какой бы огромный массив у вас не был, вы бы не получили никогда более 150IOPS, так как работал бы только один диск (на флеше получили бы побольше).
Но, что прекрасно, приложения генерят несколько потоков данных, которые могут обрабатываться параллельно. То есть в канал сразу полетят, например, 50 потоков, с каждого можно выжать 1000IOPS, вот у вас и 50к IOPS получилось.
Много раз видел перегруженные СХД, в которых при задержке 20-30мс было около 100к IOPS.
Это давний холивар, мнения по этому вопросу у каждого свое. Ваше мнение довольно распространенное, хотя его поклонников становится все меньше.
Я просто не вижу смысла выделять целый класс устройств по одному, такому незначительному признаку. Завтра какой-нибудь Huawei возьмет и добавит к своей младшей линейке поддержку FICON (ну еще пару лет потратит на сертификацию), не будем же мы S2600T называть Hi-end?
в последнее время, если смотреть на вендоров, то Hi-end оборудование часто выделяется только за счет своей цены=) Например, NetApp FAS8080 ничем архитектурно не отличается от 8020, а они называют его Hi-end.
Это уже вопрос больше религии, чем реальное разделение.
Все вышенаписанное — не более чем мои размышления. Точку зрения не навязываю, это просто мое воззрение на сегодняшний рынок СХД.
я поклонник мнения, что Hi-end массивы отделяются от midrange надежностью, внутренней архитектурой. Но в сообщении выше top of mid-range я тоже отнес к категории Hi-end.
Ficon почти мертв и скоро совсем не останется таких массивов=)
в статье нашел упоминание про 16Gb FC. 16Gb можно более чем сравнивать с 40Гбит.
А еще я вам один секрет скажу, сейчас никто (почти) не покупает даже 16Gb FC (хотя уже вышел 32Gb), потому что пропускная способность канала значит не так много, когда транспорт построен грамотно. Так как для всех подключений стораджа к серверам используется multipathing, то это минимум 2, а обычно 4 линка, то есть 32Gb.
Я знаю ооочень маленькое количество массивов, которые способны выдать такой поток данных и не умереть. Это High-end массивы, которые обычно подключаются гораздо бОльшим числом линков.
Так что все эти 40Gb — далеко не показатель.
Еще бы, как же иначе, ведь они продают это железо. Странно, если бы они его не предлагали всем подряд.
С каких пор FC стал медленным? Много вы знаете внедрений IB в качестве транспорта систем хранения данных?
Простите за вопрос, а вы хорошо знаете предмет?
После слов про мощность x86 > RISC, а также после сравнение ARM и RISC от IBM я сильно в этом засомневался.
Коллеги, мне кажется, у вас тут небольшое недопонимание произошло на почве SnapRestore.
Snaprestore — это технология восстановления из снэпшота средствами массива. Она работает на всех протоколах доступа.
Но на файловом уровне можно восстановить любой файл (например, vmdk диск), а на блочном — только LUN целиком. netto прав в том, что snaprestore работает всегда и везде, но восстановить конкретную ВМ его средствами, как верно подметил
TheRealGostev, возможно только на nfs.
Действительно, не обязан. Может я как-то не правильно выражаюсь, но я не требую, просто рассказал что мне не хватает.
Вдруг veeam прислушается и реализует хотя бы часть? Мы же все от этого выиграем, даже veeam — он сможет протестировать на нас новые фичи.
В целом я с Вами абсолютно согласен. Но не во всем:
Эндпоинт в роли домашнего пользователя
Кажется мне, что это не совсем так. Veeam уже давно просили добавить функционал бэкапирования физических машин, и очень вероятно, что VEB — это как раз песочница для отработки технологии.
Вы просите (даже требуете)
Ну не правда, я рассуждаю о том, что мне не хватает. Ведь коллеги хотят фидбек, я его даю. Никого ни в чем не обвиняю, не ругаю, просто рассказываю что мне не хватает.
а мужики-то не знают! (с).
Многие мужики знают, правда. Я не против скриптов, совсем нет. Они важны, нужны, а умение их писать — это действительно скилл. Просто есть у меня такое мнение: если вы покупаете продукт резервного копирования, то вся функциональность резервного копирования вашей организации (или дома) должна быть реализована в его рамках, все скрипты и настройки должны быть также реализованы в его пределах. Компания, которая выпускает этот софт тестирует различные сценарии, выпускает гайды, проверяет совместимость различных настроек и т.п. Интеграцию с вашими скриптами проверять никто не будет.
Это мнение возникло не просто так, оно «написано кровью» клиентов, с которыми я работал. Я видел очень много случаев, когда рядом лежащие скрипты переставали грамотно работать при изменениях в основной программе РК, в итоге это приводило к отсутствию нужного бэкапа, когда наставал час X. Остаться с битой business-critical базой Oracle после её развала никому не пожелаешь.
И да, это все больше относится к дорогим enterprise продуктам, явно не к VEB, но я стараюсь применять схожие подходы к реализации СРК даже для дома. Поэтому не хочу писать скрипты=) Либо уж все скриптами и поддерживать их самостоятельно, либо использовать стороннюю программу.
Я умею пользоваться и командной строкой, и политиками, и расписаниями, и скрипт написать могу. Но многие — нет. К тому же я считаю, что вся нужная функциональность должна быть реализована средством одного продукта, либо управляться им. Я активно против дополнения функционала своими собственными скриптами, так как это ведет ко многим проблемам, придется своими силами постоянно поддерживать функционирование своих костылей.
Моя работа связана с СХД и резервным копированием, я уже вдоволь насмотрелся на то, как люди мучаются со скриптами, которыми управляют админы. Так что мой комментарий — это своеобразный список того, что я хотел бы видеть в продукте РК.
По поводу forever increment. Меня беспокоит, что битый блок будет где-нибудь в файле, который больше не будет обновляться (например, в ядре Windows). После этого копия будет вечно невалидна, если не начать цепочку заново. Отдельные Full и переименование директорий — это костыли, так делать архитектурно неправильно.
Недавно установил ваш продукт, все нравится, интерфейс хорош, бэкапит очень быстро.
Но есть несколько НО, которые портят картину:
Первое и самое главное: я не очень доверяю механизму forever increment. Что если по каким-то причинам increment копия окажется битой, а veeam этого не заметит? Это ведь будет означать, что восстановление полной копии уже никогда не будет выполнено корректно, так как больше full бэкапа никогда не будет. Может быть можно делать промежуточные full хотя бы из командной строки?
Мне очень понравился механизм отправки e-mail сообщений, классная штука! Но у меня на работе прокси, и функция оказалась бесполезной, она не работает.
Схема с одним заданием выглядит ну совсем несерьезной. Вы же планируете это потом допилить и всунуть во взрослый veeam, ну там то она уж точно понадобится! Пора уже реализовать.
Также у меня вопрос — можно ли организовать проведения бэкапа при выключении компьютера?
А в целом спасибо за хорошую и бесплатную программу!
А на чем зарабатывают такие компании? Я так понимаю, что разработка движка — дорогое удовольствие.
На пожертвования? Или оказывают какие-то услуги по интеграции движка в игру?
Странно видеть все это от технического человека, если честно.
Такими речами кормят нас постоянно, сколько я работаю в этой сфере, столько слышу подобное.
Ну подешевеет флеш, ну будут его использовать побольше, может даже не для совсем уж критичных задач. И что?
Причем тут docker и NetApp со своим флешом? Как они связаны? Если докер будет работать на Неттаповском флеше все станет с ног на голову?
Как облако (в нотации NetApp, конечно) будет уменьшать необходимость админов? Data Ontap в облаке нужно настраивать так же, как и не в облаке (да-да, диски менять не надо...)
Мои глаза(((
Вы вообще СХД видели что такое?
Сервер с примотанной скотчем полкой — это не СХД.
Резервирования контроллеров нет, RAID нет, поддержки нет (а это существенная часть расходов, если что), функционала толком нет. Покупать СХД если вам нужен сервер с дисками действительно не стОит, перед СХД стоЯт совсем другие задачи.
Чтобы ветер обдувал лицо надо опускать все стекла, причем дует только сбоку, лобовое не опускается. Поменял обратно на лошадь и слава Богу!
По теме:
Аппаратная не для того, чтобы разговаривать. Если вы хотите увеличить плотность компоновки, очевидно, что придется подводить туда больше питания и охлаждения. Как вы хотели иначе? Просто думать об этом надо до проекта, а не после.
Вообще это относится ко всем вашим статьям про NetApp, спасибо за ваш труд!
Не знаю, актуально ли еще, но напишу:
Вы ошиблись дважды. Если у вас задержка 1мс, то вы успеете 1000 IOPS получить, а не 1. Но это произойдет только в том случае, если у вас IOPS следуют друг за другом и каждый следующий ждет подтверждения предыдущего. Если бы приложения работали именно так, то какой бы огромный массив у вас не был, вы бы не получили никогда более 150IOPS, так как работал бы только один диск (на флеше получили бы побольше).
Но, что прекрасно, приложения генерят несколько потоков данных, которые могут обрабатываться параллельно. То есть в канал сразу полетят, например, 50 потоков, с каждого можно выжать 1000IOPS, вот у вас и 50к IOPS получилось.
Много раз видел перегруженные СХД, в которых при задержке 20-30мс было около 100к IOPS.
Надеюсь, смог донести мысль.
Я просто не вижу смысла выделять целый класс устройств по одному, такому незначительному признаку. Завтра какой-нибудь Huawei возьмет и добавит к своей младшей линейке поддержку FICON (ну еще пару лет потратит на сертификацию), не будем же мы S2600T называть Hi-end?
в последнее время, если смотреть на вендоров, то Hi-end оборудование часто выделяется только за счет своей цены=) Например, NetApp FAS8080 ничем архитектурно не отличается от 8020, а они называют его Hi-end.
Это уже вопрос больше религии, чем реальное разделение.
Все вышенаписанное — не более чем мои размышления. Точку зрения не навязываю, это просто мое воззрение на сегодняшний рынок СХД.
Ficon почти мертв и скоро совсем не останется таких массивов=)
А еще я вам один секрет скажу, сейчас никто (почти) не покупает даже 16Gb FC (хотя уже вышел 32Gb), потому что пропускная способность канала значит не так много, когда транспорт построен грамотно. Так как для всех подключений стораджа к серверам используется multipathing, то это минимум 2, а обычно 4 линка, то есть 32Gb.
Я знаю ооочень маленькое количество массивов, которые способны выдать такой поток данных и не умереть. Это High-end массивы, которые обычно подключаются гораздо бОльшим числом линков.
Так что все эти 40Gb — далеко не показатель.
Тут я даже спорить не стану, все верно. Только в статье IBM Power, а вы про ARM. Это более чем не одно и то же.
С каких пор FC стал медленным? Много вы знаете внедрений IB в качестве транспорта систем хранения данных?
После слов про мощность x86 > RISC, а также после сравнение ARM и RISC от IBM я сильно в этом засомневался.
Snaprestore — это технология восстановления из снэпшота средствами массива. Она работает на всех протоколах доступа.
Но на файловом уровне можно восстановить любой файл (например, vmdk диск), а на блочном — только LUN целиком.
netto прав в том, что snaprestore работает всегда и везде, но восстановить конкретную ВМ его средствами, как верно подметил TheRealGostev, возможно только на nfs.
Вдруг veeam прислушается и реализует хотя бы часть? Мы же все от этого выиграем, даже veeam — он сможет протестировать на нас новые фичи.
Кажется мне, что это не совсем так. Veeam уже давно просили добавить функционал бэкапирования физических машин, и очень вероятно, что VEB — это как раз песочница для отработки технологии.
Ну не правда, я рассуждаю о том, что мне не хватает. Ведь коллеги хотят фидбек, я его даю. Никого ни в чем не обвиняю, не ругаю, просто рассказываю что мне не хватает.
Многие мужики знают, правда. Я не против скриптов, совсем нет. Они важны, нужны, а умение их писать — это действительно скилл. Просто есть у меня такое мнение: если вы покупаете продукт резервного копирования, то вся функциональность резервного копирования вашей организации (или дома) должна быть реализована в его рамках, все скрипты и настройки должны быть также реализованы в его пределах. Компания, которая выпускает этот софт тестирует различные сценарии, выпускает гайды, проверяет совместимость различных настроек и т.п. Интеграцию с вашими скриптами проверять никто не будет.
Это мнение возникло не просто так, оно «написано кровью» клиентов, с которыми я работал. Я видел очень много случаев, когда рядом лежащие скрипты переставали грамотно работать при изменениях в основной программе РК, в итоге это приводило к отсутствию нужного бэкапа, когда наставал час X. Остаться с битой business-critical базой Oracle после её развала никому не пожелаешь.
И да, это все больше относится к дорогим enterprise продуктам, явно не к VEB, но я стараюсь применять схожие подходы к реализации СРК даже для дома. Поэтому не хочу писать скрипты=) Либо уж все скриптами и поддерживать их самостоятельно, либо использовать стороннюю программу.
Спасибо большое за развернутые советы! Наверняка многие смогут ими воспользоваться.
Я умею пользоваться и командной строкой, и политиками, и расписаниями, и скрипт написать могу. Но многие — нет. К тому же я считаю, что вся нужная функциональность должна быть реализована средством одного продукта, либо управляться им. Я активно против дополнения функционала своими собственными скриптами, так как это ведет ко многим проблемам, придется своими силами постоянно поддерживать функционирование своих костылей.
Моя работа связана с СХД и резервным копированием, я уже вдоволь насмотрелся на то, как люди мучаются со скриптами, которыми управляют админы. Так что мой комментарий — это своеобразный список того, что я хотел бы видеть в продукте РК.
По поводу forever increment. Меня беспокоит, что битый блок будет где-нибудь в файле, который больше не будет обновляться (например, в ядре Windows). После этого копия будет вечно невалидна, если не начать цепочку заново. Отдельные Full и переименование директорий — это костыли, так делать архитектурно неправильно.
Но есть несколько НО, которые портят картину:
Также у меня вопрос — можно ли организовать проведения бэкапа при выключении компьютера?
А в целом спасибо за хорошую и бесплатную программу!
Возьмем общее число играющих людей. Более 50% этих людей играет и пользуется Windows, а не Linux.
Нет, утверждение там было что "те кто играет в игры, все же больше на Windows, чем на Linux."
Больше — значит более 50% от общего числа.
На пожертвования? Или оказывают какие-то услуги по интеграции движка в игру?
Такими речами кормят нас постоянно, сколько я работаю в этой сфере, столько слышу подобное.
Ну подешевеет флеш, ну будут его использовать побольше, может даже не для совсем уж критичных задач. И что?
Причем тут docker и NetApp со своим флешом? Как они связаны? Если докер будет работать на Неттаповском флеше все станет с ног на голову?
Как облако (в нотации NetApp, конечно) будет уменьшать необходимость админов? Data Ontap в облаке нужно настраивать так же, как и не в облаке (да-да, диски менять не надо...)
Вы вообще СХД видели что такое?
Сервер с примотанной скотчем полкой — это не СХД.
Резервирования контроллеров нет, RAID нет, поддержки нет (а это существенная часть расходов, если что), функционала толком нет. Покупать СХД если вам нужен сервер с дисками действительно не стОит, перед СХД стоЯт совсем другие задачи.