Вы бы еще новостной сайт Нигерии привели как пруф линк. Про 60 стоек на смену, так если в стойках сервера года так 2008-2010 или еще старше, то ничего удивительного. Хотя опять же на официальных сайтах мин.обороны US ничего не находится. Ну да и бог с ним :).
Просто по началу от новости создалось впечатление, что министерство обороны США выкинет на помойку или продаст в какой-нить nag.ru все старое железо и будет жить дальше только на Nutanix-е. Но «Вау!» эффект как-то быстро улетучился :(.
ZFS имеет ряд собственных нюансов и далеко не идеальна. Если использовать ее не разобравшись в этих нюансах, то и данные потерять не долго. Не говоря уже про всякие тонкости и оптимизации для достижения хорошей производительности и т.д. Достаточно вчитаться вот в этот документ от разработчиков FreeNAS.
Как пример:
For maximum performance and reliability, you should never try to use ZFS with less than 8GB of RAM and a 64-bit system under any circumstances, regardless of the size of your pool. We typically see at least 1-2 people every week that break this rule and they lose their pools suddenly. There is no recovery if you damage your pool and ignoring this warning.
It is not recommended that VDevs contain more than 11 disks under any circumstances.
FreeNAS’ ZFS stripes data in chunks up to 128 kilobyte. If you will be using compression (default is enabled/lz4) with FreeNAS 9.2.1+ then the following slide does not apply. Compression adds a layer of complexity because each block of data will be compressed to some arbitrary smaller size, so planning for ideal block allocation is impossible.
For home users in particular, your bottleneck is certainly going to be your Gb NIC and not your pool unless you are using woefully inadequate hardware for FreeNAS.
А сама статья оставляет впечатление, что автор не в курсе, что большие вендоры тоже давно смотрят на сегмент Scale-out систем хранения и на программно определяемые СХД. И на рынке давно уже разносолье готовых решений (из коробки) на эту тему и за ваши деньги. Не все компании могут позволить себе держать штат высококвалифицированных программистов и админов, что бы пилить собственное решение под себя. По этому наравне с классическими решениями хранения, те же самые компании продвигают и продают так называемые «легко масштабируемые» Scale-out и software defined storage. A SMB 3.0 от мелкомягких не единственный протокол в мире IT, годный для получения доступа к хранимым данным ;).
С большой долей вероятности именно так и есть. Делать изо дня в день одну и ту же операцию сотни раз без смены рода деятельности — это точно прямая дорога в дурдом. Плюс таким образом я думаю решается вопрос взаимозаменяемости работников без особой потери производительности труда. Люди могут например заболеть и не выйти на работу.
FAST VP и FAST Cache — это две разные технологии, дополняющие друг друга. Сравнить их «в лоб» не получится.
FAST Cache — это именно дополнительный кэш, организованный на SSD (SLC) дисках, который позволяет нивелировать влияние резких всплесков нагрузки на области данных, расположенные на шпиндельных (SAS/NL-SAS) дисках на СХД. Перемещение данных в FAST Cache и вымывание старых данных из него происходит постоянно в течении работы. FAST Cache работает с блоками данных по 64 кб, что позволяет перемещать на SSD только действительно востребованные в текущий момент данные. «Идеальный» профиль нагрузки, когда FAST Cache показывает себя лучше всего — это обращение к случайным блокам данных и размер блока ввод/вывода не превышающий 64 кб.
FAST VP — это технология, позволяющая в зависимости от интенсивности нагрузки на конкретные данные, автоматически размещать эти данные в пределах одного дискового пула на диски с различными характеристиками производительности. Соответственно менее востребованные данные в процессе работы FAST VP перемещаются на более медленные и дешевые (1Gb/$) NL-SAS диски, а более востребованные данные на более скоростные SAS или вовсе на SSD (обычно eMLC, но возможны и SLC) диски. При этом блок, с которым работает FAST VP сейчас равен 256 мб. То есть если 50 мб в блоке размером 256 мб очень сильно нагружены, то в итоге на быстрые диски поедет весь блок из 256 мб (в том числе 206 мб менее нагруженных данных). Другая особенность работы FAST VP заключается в том, что статистика нагрузки на те или иные блоки данных собирается постоянно, а вот миграция данных между различными типами дисков осуществляется по расписанию и не чаще чем 1 раз в сутки. Есть правда возможность запускать миграцию в ручном режиме, но смысла это чаще всего не имеет.
То есть фактически FAST VP служит для автоматизации так называемого ILM (Information Life and Management), для автоматизации управления жизненным циклом информации. Когда по мере устаревания ваши данные уходят на хранение на более медленные и дешевые дисковые устройства. Н-р: кусок базы данных, который содержит данные 3-5-ти летней давности. При этом если по какой то причине эти данные вам срочно понадобились (н-р: строится какая-то аналитика или отчеты), то первым на повышение нагрузки на эти данные отреагирует Fast Cache. Отреагирует в режиме реального времени и даже в том случае если эти данные уже давно лежат на NL-SAS дисках. Если данные продолжают нагружаться, то по итогам суточного анализа, массивом может быть принято решение о перемещении этих данных на более быстрые SAS или SSD диски в пределах дискового пула. Т.е. отреагирует уже FAST VP. Еще замечу, что FAST VP может работать и вовсе без SSD дисков. Т.е. пул может быть двух-уровневым (SAS/NL-SAS, SSD/SAS и не рекомендуется, но возможен даже SSD/NL-SAS).
Вопрос, какое именно вы хотели бы увидеть в таком случае сравнение? При сравнении FAST VP и FAST Cache «в лоб» при одинаковом количестве SSD дисков будет играть большую роль заданный профиль нагрузки (размер блока IO, соотношение чтения/записи, процент рандомных IO), тип RAID выбранный для SSD дисков в пуле, тип SSD в пуле (SLC или eMLC), распределение тестовых данных в пуле между SSD дисками и обычными шпиндельными дисками. В целом, на мой взгляд, такое сравнение некорректно и не имеет смысла. Учитывая что обе технологии могут работать совместно с одними и теми же данными. При этом данные уже попавшие на SSD в пуле не будут отрабатываться через FAST Cache. FAST Cache будет работать только с теми данными, которые в пуле лежат на SAS/NL-SAS дисках.
P.s. При наличии небольшого количества SSD дисков в системе и наличии необходимых лицензии вендор рекомендует в первую очередь создавать Fast Cache.
А как обстоят дела с сервисной поддержкой на территории РФ? Срок базовой гарантии? Кто обеспечивает техническую поддержку и на каком языке (вендор, партнеры, сертифицированные сервисные центры)? Где находятся склады с запчастями в РФ или нет? И как обстоят дела с доставкой запчастей в случае поломок в течении гарантийного периода (сроки, за чей счет)?
Мягко говоря, странную утилиту вы выбрали для тестирования. Решения, подобные предложенному вами, обычно «колхозят» не под линейные операции чтения/записи. Поэтому интереснее видеть в результате теста получаемые IOPS, а не MB/s. Ну и возможности настройки теста просто удручают. Максимальный размер тестового файла в 2Gb позволяет предположить, что в итоге он большей частью поместиться в кэше на контролере сервера. Если конечно будет использоваться приличный RAID-контроллер имеющий энергонезависимый кэш. А в продаже сейчас есть SAS контроллеры имеющие до 8Gb кэша. В итоге не понятно, что будет измерять используемый вами benchmark? Скорость работы DIMM модулей в SAS контроллере? :)
Без обид, но используемый вами Untitled — это скорее утилита для домашних пользователей, которую можно использовать для измерения «производительности» дисков, стоящих в персональном компьютере. Что бы не тратить свое драгоценное время на изучение чего то более приличного :).
На вашу последнюю реплику так и хочется ответить «Так гоните их скорее поганой метлой» :).
А если по существу, то мне сравнение кажется достаточно странным. Nutanix вроде как граната другой системы. Плюс в свое время я писал коллегам, занимающимся нутаниксом список вопросов так десятков на 6-ть. Мне далеко не на все смогли ответить. В частности как будет происходить сервисная поддержка и замена запчастей в России. Ну и были вопросы по отказоустойчивости кластера Nutaix, на которые были получены ответы типа иди читай «библию» нутаникс там все есть. А так как библию писал сам Нутаникс, то там как раз скользких моментов то и нет :).
Подскажите, а почему перед тестированием не обновили XtremIO до версии прошивок 3.0.1? Насколько вижу на саппорт портале вендора прошивка доступна с «December 05, 2014». А недавно появилась версия 3.0.2 (February 06, 2015). С обновлением все еще есть какие-то проблемы? Как было на заре появления продукта? Или это связано с чем то другим?
Если есть понимание по своим задачам, которые будут использовать СХД. А так же известен профиль ввода/вывода (соотношение чтения/записи, количество IOPS/Поток в Mb/s и т.д.) и есть понимание как посчитать «свою» конфигурацию СХД. А еще вы готовы взять на себя риски перед руководством, в случае если промажете и работать все будет не так хорошо как планировалось. То да, нафиг все эти партнеры и интеграторы. И можно действовать по плану: «Хочу мороженку наполовину шоколадную, наполовину клубничную, в глазури и чтобы при +20 по цельсию не таяла в течении 15 минут.» сколько будет стоить?
Но далеко не все заказчики такие продвинутые. Поэтому на рынке и существуют компании интеграторы. Да и определение «типовая конфигурация» для СХД не совсем понятно, что должно означать. А если нет типовой конфигурации, то как сделать паблик прайс? Покомпонентно перечислять?
Типа:
Двигатель внутреннего сгорания — 1000$;
Дверь передняя правая 500$;
Руль — 100$;
и т.д.
:)?
А потом заказчик вендора будет спрашивать, а почему я не могу купить у вас машину без руля? Или без заднего моста?
А еще лучше:
— Я купил у вас машину, но она не едет.
— Но вы же не захотели покупать двигатель!
— Ну и что? У вас просто дерьмовые машины. Никогда больше к вам не приду.
Я утрирую конечно. Но на мой взгляд это часть мотивов, которыми в данном случае руководствуются «большие» вендора. Ну и $$ в глазах и в мозгах ими тоже движут :).
Угу, посмотрел, видимо путаю с их «старыми» агрегатами. А DDP вообще по логике получается «собственная реализация» Raid60 в конфигурации 8+2. D-Piece по 512 мб собранные в D-Stripe в конфигурации 8Data+2Parity итоговым размером 4 ГБ. В итоге луны, отдаваемые хостам, размазываются по этим D-Stripe. Чем-то напоминает идеологию HP 3PAR.
Если память не изменяет, то у нетапа максимальный размер дисковой группы внутри пула равно 28 шт, при этом рекомендованный размер не более то ли 14-ти, то ли 16-ти. Соответственно DDP составляется из нескольких таких дисковых групп, защищенных старым добрым Raid.
Когда я писал про дезу :) имелись в виду утверждения в комментариях.
В частности:
«По большому счёту локальные снепшоты это полноценные бекапы, которые не защищают от физического повреждения СХД.»
Вот тут дъявол и селиться :). Полноценные бэкапы — это резервные копии, защищенные от физического или логического повреждения исходных данных. И никак иначе.
Да ладно вам полемика :).
Ленты я тоже не жалую :). Лучше отдельное дисковое устройство, можно не очень дорогое но с Raid6 :). Я уже писал: " не являюсь человеком глубоко подкованным в технических особенностях СХД компании NetApp и могу ошибаться" :).
Если рассматривать концепцию и идеологию снапшотинга в общем. То снапшот — это не бэкап. В том числе потому что поврежедение исходных данных приведет к порче всех сделанных в последствии снапшотов, безотносительно вендоров и конкретных реализаций процесса. А в данном случае декларируя, что в случае NetApp конечный пользователь может не делать бэкапов, а пользовать только снапшотинг, вы на мой взгляд несколько дезинформируете неокрепшие умы.
Я не спорю, что зареплицированные на удаленный сайт снапшоты могут считаться полноценным бэкапом. Особенно если есть инструментарий, позволяющий с этим удобно работать (объектное восстановление отдельных писем или файлов и т.д.). В общем все зависит от конкретной реализации. И в ваш случай с NetApp — это скорее частная реализация. Но в целом картины мира это не меняет. Еще раз снапшотинг — это не замена резервному копированию данных.
Тут нужно уже смотреть реализацию конкретного вендора и конкретной СХД. При нормальном подходе снапшоты и клоны томов должны подключаться даже к исходному серверу как отдельные логические тома имеющие собственный HostID, а соответственно и отличную от исходной букву диска или точку монтирования.
Снапшот и бэкап (резервная копия) — это вообще разные сущности.
Снапшот — это замороженное на конкретную точку во времени состояние системы.
Консистентный снапшот — это снапшот, гарантирующий целостность данных в данной точке во времени. В частности, для того что бы сделать консистентный снапшот FS, необходимо заставить операционную систему выполнить синхронизацию всех кэшированных в оперативной памяти данных на дисковое устройство (или LUN), затем приостановить ввод/вывод на это устройство и только после этого можно создать снапшот. А затем уже разморозить ввод/вывод на диск.
Если снапшот неконсистнтный, то мы получаем состояние системы в нем примерно такое же, как если бы у сервера выключили питание на входе. То есть операционка после восстановления с такого снапшота имеет шансы «не взлететь». А если на томе была база данных, то вообще есть вероятность с ней попрощаться.
Бэкап или резервная копия данных — это отдельная полная копия данных, с которой мы можем восстановиться в том числе и на другое железо. Очень удобно делать бэкап используя как источник консистентный снапшот данных. Это позволяет не беспокоиться о том, что в процессе, например двухчасового копирования данных, данные продолжают изменяться. Так как сервисы работают и продолжают что-то писать. То есть данные даже в процессе самого бэкапа могут изменяться и в итоге мы можем получить неконсистентую резервную копию.
Поэтому сннапшотинг и бэкап — это вещи, которые очень удачно могут дополнять друг друга. Но снапшоты — это ни в коем случае не бэкап, так они не защищают от потери исходных блоков данных. А копию бэкапов в идеале необходимо хранить на удаленной площадке.
Просто по началу от новости создалось впечатление, что министерство обороны США выкинет на помойку или продаст в какой-нить nag.ru все старое железо и будет жить дальше только на Nutanix-е. Но «Вау!» эффект как-то быстро улетучился :(.
IBM есть: тут
HP есть: тут
EMC есть: тут
Или контракт с Nutanix настолько маленький и секретный, что про него ни слова на публику? :)
Страничка с контрактами превышающими 6,5 млн вечно зеленых тут, инфа вплоть до 12 мая 2015.
Или я искал неправильно? :)
Как пример:
For maximum performance and reliability, you should never try to use ZFS with less than 8GB of RAM and a 64-bit system under any circumstances, regardless of the size of your pool. We typically see at least 1-2 people every week that break this rule and they lose their pools suddenly. There is no recovery if you damage your pool and ignoring this warning.
It is not recommended that VDevs contain more than 11 disks under any circumstances.
FreeNAS’ ZFS stripes data in chunks up to 128 kilobyte. If you will be using compression (default is enabled/lz4) with FreeNAS 9.2.1+ then the following slide does not apply. Compression adds a layer of complexity because each block of data will be compressed to some arbitrary smaller size, so planning for ideal block allocation is impossible.
For home users in particular, your bottleneck is certainly going to be your Gb NIC and not your pool unless you are using woefully inadequate hardware for FreeNAS.
А сама статья оставляет впечатление, что автор не в курсе, что большие вендоры тоже давно смотрят на сегмент Scale-out систем хранения и на программно определяемые СХД. И на рынке давно уже разносолье готовых решений (из коробки) на эту тему и за ваши деньги. Не все компании могут позволить себе держать штат высококвалифицированных программистов и админов, что бы пилить собственное решение под себя. По этому наравне с классическими решениями хранения, те же самые компании продвигают и продают так называемые «легко масштабируемые» Scale-out и software defined storage. A SMB 3.0 от мелкомягких не единственный протокол в мире IT, годный для получения доступа к хранимым данным ;).
FAST Cache — это именно дополнительный кэш, организованный на SSD (SLC) дисках, который позволяет нивелировать влияние резких всплесков нагрузки на области данных, расположенные на шпиндельных (SAS/NL-SAS) дисках на СХД. Перемещение данных в FAST Cache и вымывание старых данных из него происходит постоянно в течении работы. FAST Cache работает с блоками данных по 64 кб, что позволяет перемещать на SSD только действительно востребованные в текущий момент данные. «Идеальный» профиль нагрузки, когда FAST Cache показывает себя лучше всего — это обращение к случайным блокам данных и размер блока ввод/вывода не превышающий 64 кб.
FAST VP — это технология, позволяющая в зависимости от интенсивности нагрузки на конкретные данные, автоматически размещать эти данные в пределах одного дискового пула на диски с различными характеристиками производительности. Соответственно менее востребованные данные в процессе работы FAST VP перемещаются на более медленные и дешевые (1Gb/$) NL-SAS диски, а более востребованные данные на более скоростные SAS или вовсе на SSD (обычно eMLC, но возможны и SLC) диски. При этом блок, с которым работает FAST VP сейчас равен 256 мб. То есть если 50 мб в блоке размером 256 мб очень сильно нагружены, то в итоге на быстрые диски поедет весь блок из 256 мб (в том числе 206 мб менее нагруженных данных). Другая особенность работы FAST VP заключается в том, что статистика нагрузки на те или иные блоки данных собирается постоянно, а вот миграция данных между различными типами дисков осуществляется по расписанию и не чаще чем 1 раз в сутки. Есть правда возможность запускать миграцию в ручном режиме, но смысла это чаще всего не имеет.
То есть фактически FAST VP служит для автоматизации так называемого ILM (Information Life and Management), для автоматизации управления жизненным циклом информации. Когда по мере устаревания ваши данные уходят на хранение на более медленные и дешевые дисковые устройства. Н-р: кусок базы данных, который содержит данные 3-5-ти летней давности. При этом если по какой то причине эти данные вам срочно понадобились (н-р: строится какая-то аналитика или отчеты), то первым на повышение нагрузки на эти данные отреагирует Fast Cache. Отреагирует в режиме реального времени и даже в том случае если эти данные уже давно лежат на NL-SAS дисках. Если данные продолжают нагружаться, то по итогам суточного анализа, массивом может быть принято решение о перемещении этих данных на более быстрые SAS или SSD диски в пределах дискового пула. Т.е. отреагирует уже FAST VP. Еще замечу, что FAST VP может работать и вовсе без SSD дисков. Т.е. пул может быть двух-уровневым (SAS/NL-SAS, SSD/SAS и не рекомендуется, но возможен даже SSD/NL-SAS).
Вопрос, какое именно вы хотели бы увидеть в таком случае сравнение? При сравнении FAST VP и FAST Cache «в лоб» при одинаковом количестве SSD дисков будет играть большую роль заданный профиль нагрузки (размер блока IO, соотношение чтения/записи, процент рандомных IO), тип RAID выбранный для SSD дисков в пуле, тип SSD в пуле (SLC или eMLC), распределение тестовых данных в пуле между SSD дисками и обычными шпиндельными дисками. В целом, на мой взгляд, такое сравнение некорректно и не имеет смысла. Учитывая что обе технологии могут работать совместно с одними и теми же данными. При этом данные уже попавшие на SSD в пуле не будут отрабатываться через FAST Cache. FAST Cache будет работать только с теми данными, которые в пуле лежат на SAS/NL-SAS дисках.
P.s. При наличии небольшого количества SSD дисков в системе и наличии необходимых лицензии вендор рекомендует в первую очередь создавать Fast Cache.
Без обид, но используемый вами Untitled — это скорее утилита для домашних пользователей, которую можно использовать для измерения «производительности» дисков, стоящих в персональном компьютере. Что бы не тратить свое драгоценное время на изучение чего то более приличного :).
А если по существу, то мне сравнение кажется достаточно странным. Nutanix вроде как граната другой системы. Плюс в свое время я писал коллегам, занимающимся нутаниксом список вопросов так десятков на 6-ть. Мне далеко не на все смогли ответить. В частности как будет происходить сервисная поддержка и замена запчастей в России. Ну и были вопросы по отказоустойчивости кластера Nutaix, на которые были получены ответы типа иди читай «библию» нутаникс там все есть. А так как библию писал сам Нутаникс, то там как раз скользких моментов то и нет :).
Но далеко не все заказчики такие продвинутые. Поэтому на рынке и существуют компании интеграторы. Да и определение «типовая конфигурация» для СХД не совсем понятно, что должно означать. А если нет типовой конфигурации, то как сделать паблик прайс? Покомпонентно перечислять?
Типа:
Двигатель внутреннего сгорания — 1000$;
Дверь передняя правая 500$;
Руль — 100$;
и т.д.
:)?
А потом заказчик вендора будет спрашивать, а почему я не могу купить у вас машину без руля? Или без заднего моста?
А еще лучше:
— Я купил у вас машину, но она не едет.
— Но вы же не захотели покупать двигатель!
— Ну и что? У вас просто дерьмовые машины. Никогда больше к вам не приду.
Я утрирую конечно. Но на мой взгляд это часть мотивов, которыми в данном случае руководствуются «большие» вендора. Ну и $$ в глазах и в мозгах ими тоже движут :).
Вопрос в «чем консистентный снапшот отличается от бэкапа, кроме места хранения?» я надеюсь у вас тоже отпал? :)
В частности:
«По большому счёту локальные снепшоты это полноценные бекапы, которые не защищают от физического повреждения СХД.»
Вот тут дъявол и селиться :). Полноценные бэкапы — это резервные копии, защищенные от физического или логического повреждения исходных данных. И никак иначе.
Ленты я тоже не жалую :). Лучше отдельное дисковое устройство, можно не очень дорогое но с Raid6 :). Я уже писал: " не являюсь человеком глубоко подкованным в технических особенностях СХД компании NetApp и могу ошибаться" :).
Если рассматривать концепцию и идеологию снапшотинга в общем. То снапшот — это не бэкап. В том числе потому что поврежедение исходных данных приведет к порче всех сделанных в последствии снапшотов, безотносительно вендоров и конкретных реализаций процесса. А в данном случае декларируя, что в случае NetApp конечный пользователь может не делать бэкапов, а пользовать только снапшотинг, вы на мой взгляд несколько дезинформируете неокрепшие умы.
Я не спорю, что зареплицированные на удаленный сайт снапшоты могут считаться полноценным бэкапом. Особенно если есть инструментарий, позволяющий с этим удобно работать (объектное восстановление отдельных писем или файлов и т.д.). В общем все зависит от конкретной реализации. И в ваш случай с NetApp — это скорее частная реализация. Но в целом картины мира это не меняет. Еще раз снапшотинг — это не замена резервному копированию данных.
Снапшот и бэкап (резервная копия) — это вообще разные сущности.
Снапшот — это замороженное на конкретную точку во времени состояние системы.
Консистентный снапшот — это снапшот, гарантирующий целостность данных в данной точке во времени. В частности, для того что бы сделать консистентный снапшот FS, необходимо заставить операционную систему выполнить синхронизацию всех кэшированных в оперативной памяти данных на дисковое устройство (или LUN), затем приостановить ввод/вывод на это устройство и только после этого можно создать снапшот. А затем уже разморозить ввод/вывод на диск.
Если снапшот неконсистнтный, то мы получаем состояние системы в нем примерно такое же, как если бы у сервера выключили питание на входе. То есть операционка после восстановления с такого снапшота имеет шансы «не взлететь». А если на томе была база данных, то вообще есть вероятность с ней попрощаться.
Бэкап или резервная копия данных — это отдельная полная копия данных, с которой мы можем восстановиться в том числе и на другое железо. Очень удобно делать бэкап используя как источник консистентный снапшот данных. Это позволяет не беспокоиться о том, что в процессе, например двухчасового копирования данных, данные продолжают изменяться. Так как сервисы работают и продолжают что-то писать. То есть данные даже в процессе самого бэкапа могут изменяться и в итоге мы можем получить неконсистентую резервную копию.
Поэтому сннапшотинг и бэкап — это вещи, которые очень удачно могут дополнять друг друга. Но снапшоты — это ни в коем случае не бэкап, так они не защищают от потери исходных блоков данных. А копию бэкапов в идеале необходимо хранить на удаленной площадке.