Вы же наверняка не думали, что ADP это просто разбиение дисков на партиции?
Это не объединение нескольких разных по геометрии дисков в одну, ведь диски физически то одинаковые, с одинаковой производительностью.
В конце концов у вас всегда остаётся вариант создать отдельный агрегат.
Давайте рассмотрим конкрентый случай, когда же стоит этот самый вопрос «добавлять ли диски в агрегат к более короткой рейд группе?». Такое может произойти:
Если у вас была собрана Active-Active конфигурация т.е. у вас уже есть два агрегата на каждом контроллере из 11 дисков. И логично было бы увеличить длинну каждой рейд-группы, хотябы из тех соображений чтобы получить больше полезного пространства (не тартиться на лишние Parity диски). В таклм случае я бы предложил поступить следующим образом:
Когда вам приезжает ещё одна полка, вы можете создать на этой полке новый агрегат, в онлайне мигрировать вольюмы с одного из старых агрегатов построенных на укороченных дисках. После этого поменять у высвобожденных укороченных дисков овнершип на овнершип соседа. После чего добавить высвобожденные укороченные диски вагрегат к таким же дискам.
Если же у вас уже есть Active-Passive конфигурация, и вы докупили ещё полку с дисками, добавлять их в тот же агрегат нет смысла из соображений полезного пространства, так как 2 парити диска всё-равно будут потеряны. Другими словами в таком случае вам рационально было бы превратить вашу Active-Passive конфигурацию в Active-Active и получить такое же полезное пространство. Т.е. на первой ноде будем иметь один большой агрегат из всех дисков которые укорочены, а на пасивной ноде собрать агрегат из новых, не укороченных дисков и сделать её активной.
А если вы сразу покупали 48 дисков или более, то сразу собираете Active-Active конфигурацию по схеме приведённой выше.
Другими словами ситуация с агрегатом, состоящим из двух типов дисков маловероятна
Я зайду издали и отвечу чуть шире, чтобы этот ответ мог пригодиться более широкой аудитории.
Во-первых стоит сказать, что SSD диски совсем не так устроены.
И они более надежны чем вращающиеся диски, к примеру стандартный промышленный диск SAS 10к имеет 1,6 миллиона часов ожидаемого срока службы до сбоя (MTBF), промышленный SSD имеет 2 миллиона часов.
Во-вторых они более быстрые, а это очень важно в процессе реконструкции RAID, если данные будут быстро восстановлены у нас очень сильно уменьшается вероятность выхода ещё одного диска из строя в процессе реконструкции и это опять косвенно улучшает их надёжность.
Из-за этого у систем NetApp FAS для дисков SATA/NL-SAS размер RAID-DP группы максимум 20 (18+2) дисков, в то время как для SAS/SSD это 28 дисков (26+2).
И я не буду здесь наверное приводить формулы расчёта надёжности RAID группы на основе скорости восстановления и MTBF, потому что легко догадаться, что имея больше MTBF и выше скорость надёжность будет выше по сравнению с HDD.
По внутренним подсчётам даже в самом худшем случае интенсивности перезаписи SSD должен прожить больше 5 лет. И здесь мы плавно переходим к следующему пункту.
SSD имеют стандартную гарантию 3 года, которая может быть расширена до 5 лет. В течении всего этого времени не зависимо от интенсивности использования SSD диска, NetApp будет бесплатно менять эти диски.
NetApp рекомендует продлевать гарантию, если это возможно, или менять все компоненты системы на которые она закончилась.
cDOT периодически, (Обычно в 1 час ночи) запускает процесс disk scrubbing который проверяет блоки (по умолчанию проверка включена, её можно отключать) данных на соответствие чексуммам (вы же помните что у нетапа, и многих других уважаемых вендоров, у каждого блока есть чексумма?) и в случае не соответствия восстановит этот блок в новое место при помощи RAID
cDOT также отслеживает состояние любого, в том числе и SSD диска и в случае увеличения числа возникающих ошибок система отправит такой диск в «maintenance center» если есть 2 Spare диска (по умолчанию) иначе система сразу пометит диск как битый и не станет пытаться его проверить и оживить. Если отключить проверку наличия 2х Spare дисков, система отправит диск в maintenance center если обнаружит сбойный диск.
И конечно же cDOT отслеживает состояние износа SSD. В случае обнаружения перечисленных ошибок система может запустить Rapid Cloning (и не запустит, если физически выдернуть рабочий диск на ходу) это процесс копирования всего что можно скопировать с диска на Spare перед тем как пометить его как битый или вывести в maintenance center, а всё что не получается скопировать будет восстановлено при помощи RAID.
После того как диск попадает в maintenance center он проходит ряд тестов и если система решит, что он повреждён он будет помечен как битый.
После того, как диск помечен как битый, система подключенная к AutoSupport отправит запрос на замену этого диска и в течении Next Bussiness Day после подтверждения инженером NetApp (это базовая гарантия, которая как минимум работает 3 года) новый диск бесплатно будет доставлен заказчику.
В системах NetApp доступна команда для просмотра состояния износа ячеек SSD
Общий алгоритм следующий:
Обратитесь к вашему дистрибьютору, попросите дать оборудование из демо-фонда на подмену, запишитесь в очередь заранее.
Спланируйте переезд с начала года до весны, когда спрос на демо оборудование минимальный.
Или договоритесь о миграции с авторизированным интегратором за деньги.
Контакты дистрибьютора/интегратора может подсказать локальный офис NetApp.
Полностью с вами согласен.
Общее правило для LACP гласит, что количество хостов должно быть равное или больше чем линков по которым необходимо балансировать нагрузку, и чем больше хостов тем более вероятно что они более равномерно утилизируют пропускную способность всех агрегированных линков.
Но можно и не надеяться на вероятность, а высчитать подходящие IP адреса, чтобы утилизировать все линки.
Но к счастью обычно число хостов в ЦОД на намного больше числа линков. По этому для большинства ЦОД ов это совсем не проблема.
Кроме того если речь про 10Гб линки, как в нашем случае, то нужно еще постараться чтобы загрузить хотя-бы один 10Гб линк.
Посему возвращаюсь к своему первоначальному утверждению, что разницы В ПРАВИЛЬНО НАСТРОЕННОЙ ИНФРАСТРУКТУРЕ между блочным протоколами и nfs быть не должно.
Я бы предположил, что диски нагруженные от хостов могут влиять на root-агрегаты, но не наоборот.
Именно по-этому у нас Root-Data partitioning есть только
на FAS2240/25XX истемах, предполагая что на этих системах на столько большой нагрузки не будет, чтобы вызвать это негативное влияние.
на AFF, где исспользуются высокоскоросные SSD, чтобы опять таки не вызвать негативного влияния.
Сама cDOT читает конфиги с root-агрегатов и пишет логи, в общем она генерирует совсем не много дисковых операций.
Статистики к сожалению нет. Но есть множество систем работающих в продакшн в которых отрицательного влияния одно на другое незамечено.
Такие дорогие игрушки расчитаны на сотни и тысячи жестких дисков.
И во-первых на фоне такого количества дисков 4-6 дисков совсем ничего не значят.
Во-вторых возвращаемся к вопросу сосуществования всех уровней отказоустойчивости и стабильной, предсказуемой производительности. А как только дело касается выбора между производительностью с отказоустойчивостью и экономией 4-6 дисков, мы сразу же возвращаемся к п.1.
И в третьих агрумент «это даже есть в SOHO» для мира ентерпрайз СХД вообще не звучит. Ну вот к примеру в домашнем синолоджи или кюнапе есть встроенный торент клиент, а в ентерпрайз нет. Ну да нет. Ентерпрайз не ориентируется на SOHO. точно тоже самое можно сказать про SOHO, что вот посмотрите в Enterprise есть интеграция с резервным копированием на ленточки, а в SOHO нет.
Да, я согласен что появление партишенинга говорит о том, что он всё-же востребован, именно востребован миром Enterprise потребителей, а не тем, «что это даже есть в SOHO». Я бы даже сказал похожая технология нашла своё применение и в ентерпрайз, но это не значит что она там была обязана быть просто, «чтобы было». На всё есть свои причины.
Это абсолютно разные продукты для разных целевых аудиторий, финансовых возможностей, требований к отказоустойчивости, масштабированию, производительности и её предсказуемости.
Я скажу больше, если бы не архитектурная необходимость в наличии root-агрегатов в cDOT, Root-Data партишиненга вообще не было бы.
В мире админов хостов это действительно может показаться странным. Но в мире администраторов СХД это вполне естесственно и понятно.
Потомучто это два близких, но совершенно разных мира.
Вот кпримеру админы Linux могут запустить команду удаления системных файлов, обладая root правами, и вообще в этом мире действует идеология: «больше функционала», «нет ограничений у суперпользователя», «всё и сразу», «если админ делает глупости, это его проблемы».
В мире же СХД действует совсем другая идеология: максимум отказоустойчивости, безопасности и производительности, админ не может делать всё если это противоречит первым трем утверждениям. Многие веши заблокированы для админа СХД, ему не дают права «делать всё» и стараются максимум оградить от ошибок.
В мире СХД очень важно чтобы партиционирование не повлияло на производительность и безопасность, и вписалось во все уровни обеспечения отказоустойчивости СХД, по-этому партиционирование только сейчас помошло на помошь системным разделам.
Когда у вас есть связка на подобии той которая описана в статье, а именно FlexFabric, Nexus 5k, NetApp FAS у нас есть выбор какой протокол запускать по конвергентным линкам FCoE/iSCSI/NFS для VMware. В нашем случае можно по одним и тем же линкам запустить все эти протоколы сразу. Важно отметить что для СХД NetApp все перечисленные протоколы работают практически одинаково быстро. Стоит также отметить что протокол NFS в продуктах VMWare появился именно с подачи NetApp.
С точки зрения работы с VMware NFS протокол более удобен в плане резервного копирования/восстановления, клонирования, тонкого провиженинга (Thing Provitioning) и Дедубликации в связке с СХД NetApp.
Когда хранилище отдаёт блочное устройство на котором потом живёт файловая система, а поверх неё лежат виртуалки, то СХД не знает о том что там и где на самом деле лежит. Когда же cистема хранения (не гипервизор) делает снепшоты или клоны с блочного устройства она не может отделить одни виртуальные машины от других, по-этому в снепшоте/клоне будут находиться все виртуальные машины. Если откатываться на ранее сделанный снепшот, то все данные будет откачены назад.
По-этому удобнее когда СХД управляет файловой системой и соответственно знает о том что где лежит. Когда мы делаем снепшот с файловой шары NFS, то как и в случае блочного устройства откатить мы можем только всю шару целиком, но при этом можем поштучно выборочно клонировать виртуалки средствами хранилища, не нагружая гипервизор. После снятия снепшота все виртуалки зафиксированные в снепшоте будут видны из специальной папки .snapshot в корне NFS датастора, и любая виртуальная машина может быть от туда восстановлена или скопирована просто операцией копирования.
Зачем вообще исспользовать снепшоты/клоны хранилища?
На практике использовать снепшоты/клоны NetApp очень выгодно, так как они, в отличае VMWare снепшотов, совсем никак не влияют на производительность всей системы. Напомню, что VMware не рекомендует исспользовать свои снепшоты на высоконагруженных вируальных машинах, потому что снепшоты VMWare влияют на производительность виртуальной машины потому-что работают по технологии CoW, чем больше снепшотов, тем хуже работает виртуальная машина.
ThingProvitioning / Дедубликация на хранилище
ThingProvitioning который исспользуется на СХД NetApp FAS тоже не влияет на производительность.
Когда вы исспользуете эти технологии на стороне хранилища, то высвобожденное пространство в случае NFS возращается «внутрь» файловой шары и может исспользоваться живущими на ней виртуалками, в случае блочного хранения высвобожденное какбы во вне луна (можно создать ещё один лун), а не внутрь.
Блочные протоколы FC/FCoE/iSCSI удобно исспользовать для загрузки серверов. Важным преимуществом блочных протоколов перед NFS является наличие встроенного механизма мультипасинга и балансировки нагрузки. Так как у NFS нет мультипасинга, его роль должен выполнять коммутатор и технологии на подобии vPC и LACP. Также протоколы FC/FCoE устроены таким образом, что они не теряют свои фреймы, это кстати часто является причиной более низких задержек чем у Ethernet. К счастью Nexus 5k поддерживает DCB (lossless Ethernet), vPC, LACP что позволяет полностью компенсировать все эти недостатки NFS.
Подскажите, для работы DeviceHive, доступ к интернету нужен всгда или только в момент конфигурирования?
И можно ли исспользовать DeviceHive с домашними контроллерами умного дома?
Подскажите, а есть устройства с GPIO на подобии ESP8266, но исспользуещие BLE вместо WiFi?
Из-за высокого потребления электроэнергии ESP8266 не совсем идеальное решение. Другими словами ESP8266 будет всегда исспользоваться только там, куда можно подвести питание или куда можно установить относительно крупную батарею.
И соответственно в продолжение предыдущей мысли, логично предположить, что эта проблема могла бы быть решена заменой WiFi на BLE.
Этому должен попрепятствовать уровень сервиса, который необходимо преобрести вместе с FlexPod.
Обязательным требованием по сапорту для FlexPod есть уровни сервиса не ниже Cisco SnartNet и NetApp Support Edge Premium.
Футболить между вендорами точно не смогут, для этого специально разработан механизм в рамках кооперативного сапорта.
Если к примеру кейс по нетапу застрял, то есть регламентированное время для SupportEdge когда кейс будет подниматься выше и выше доходить до уровня руководителя поддержки вплоть до вицепрезидента департамента поддержки, если он не был разрешен.
К сожалению более детально внутреннему устройство кооперативного сапорта не подскажу.
Что касается других вендоров, в том числе моно-вендоров, вы же понимаете, что к примеру сетевой отдел поддержки, отделы разнообразного софт, отделы СХД и серверов это все-равно разные отделы, разные специалисты. А все эти отделы как правило это купленные разнородные компании ныне живущие под одним брендом, так что большой разницы не вижу.
Одновременно изображено по двум причинам: 1) так действительно можно сделать и это будет работать 2) чтобы показать что можно FC и/или FCoE. Ethernet изображен по двум причинам: 1) чтобы показать что это две ноды одной НА системы (если нод больше, обязательно понадобится свич). 2) внешний кластерный линк обязательный аксесуар операционной системы Clustered DataONTAP.
Что такое РОИ, я был не в курсе, ссылки на сайт небыло, я предположил, что это как и предыдущее слово опечатка.
Во всех четырех тезисах первого коментария оговаривалось только про наличие проблемы, без описания как именно это сделать.
К примеру по первому и второму тезисам не говориться как именно проверять личность. Вариантов масса. К примеру паспорт или мобильный или идентификационный код или…
По третьему тезису согласен, что ответ практически очевиден. Но вообще-то можно предположить к вариант «удержался».
Под четвертым вариантом опять же нет уточнения. К примеру скрывать всех подряд или дать юзеру чек бокс с вопросом хочет ли он чтобы его ФИО небыло видно.
Относительно числа голосовавших точно также нет однозначности в оригинальном комментарии. Оговаривается проблема накрутить без уточнения способа ее решения.
Как видите я не зря переспросил автора комментария, какие конкретно, предложил бы улучшения. Так как его тезисы нуждаются в дополнении.
Я совсем никак не отношусь к сайту петиций, просто собрал все петиции по ИТ в одном месте, чтобы привлечь к ним целевую аудиторию, так как сейчас простого и толкового поиска там нет.
Это не объединение нескольких разных по геометрии дисков в одну, ведь диски физически то одинаковые, с одинаковой производительностью.
В конце концов у вас всегда остаётся вариант создать отдельный агрегат.
Давайте рассмотрим конкрентый случай, когда же стоит этот самый вопрос «добавлять ли диски в агрегат к более короткой рейд группе?». Такое может произойти:
Если у вас была собрана Active-Active конфигурация т.е. у вас уже есть два агрегата на каждом контроллере из 11 дисков. И логично было бы увеличить длинну каждой рейд-группы, хотябы из тех соображений чтобы получить больше полезного пространства (не тартиться на лишние Parity диски).
В таклм случае я бы предложил поступить следующим образом:
Когда вам приезжает ещё одна полка, вы можете создать на этой полке новый агрегат, в онлайне мигрировать вольюмы с одного из старых агрегатов построенных на укороченных дисках. После этого поменять у высвобожденных укороченных дисков овнершип на овнершип соседа. После чего добавить высвобожденные укороченные диски вагрегат к таким же дискам.
Если же у вас уже есть Active-Passive конфигурация, и вы докупили ещё полку с дисками, добавлять их в тот же агрегат нет смысла из соображений полезного пространства, так как 2 парити диска всё-равно будут потеряны. Другими словами в таком случае вам рационально было бы превратить вашу Active-Passive конфигурацию в Active-Active и получить такое же полезное пространство. Т.е. на первой ноде будем иметь один большой агрегат из всех дисков которые укорочены, а на пасивной ноде собрать агрегат из новых, не укороченных дисков и сделать её активной.
А если вы сразу покупали 48 дисков или более, то сразу собираете Active-Active конфигурацию по схеме приведённой выше.
Другими словами ситуация с агрегатом, состоящим из двух типов дисков маловероятна
В системах NetApp доступна команда для просмотра состояния износа ячеек SSD
Обратитесь к вашему дистрибьютору, попросите дать оборудование из демо-фонда на подмену, запишитесь в очередь заранее.
Спланируйте переезд с начала года до весны, когда спрос на демо оборудование минимальный.
Или договоритесь о миграции с авторизированным интегратором за деньги.
Контакты дистрибьютора/интегратора может подсказать локальный офис NetApp.
Общее правило для LACP гласит, что количество хостов должно быть равное или больше чем линков по которым необходимо балансировать нагрузку, и чем больше хостов тем более вероятно что они более равномерно утилизируют пропускную способность всех агрегированных линков.
Но можно и не надеяться на вероятность, а высчитать подходящие IP адреса, чтобы утилизировать все линки.
Но к счастью обычно число хостов в ЦОД на намного больше числа линков. По этому для большинства ЦОД ов это совсем не проблема.
Кроме того если речь про 10Гб линки, как в нашем случае, то нужно еще постараться чтобы загрузить хотя-бы один 10Гб линк.
Посему возвращаюсь к своему первоначальному утверждению, что разницы В ПРАВИЛЬНО НАСТРОЕННОЙ ИНФРАСТРУКТУРЕ между блочным протоколами и nfs быть не должно.
Именно по-этому у нас Root-Data partitioning есть только
Сама cDOT читает конфиги с root-агрегатов и пишет логи, в общем она генерирует совсем не много дисковых операций.
Статистики к сожалению нет. Но есть множество систем работающих в продакшн в которых отрицательного влияния одно на другое незамечено.
Да, я согласен что появление партишенинга говорит о том, что он всё-же востребован, именно востребован миром Enterprise потребителей, а не тем, «что это даже есть в SOHO». Я бы даже сказал похожая технология нашла своё применение и в ентерпрайз, но это не значит что она там была обязана быть просто, «чтобы было». На всё есть свои причины.
Это абсолютно разные продукты для разных целевых аудиторий, финансовых возможностей, требований к отказоустойчивости, масштабированию, производительности и её предсказуемости.
Соответственно функционал совершенно разный.
В мире админов хостов это действительно может показаться странным. Но в мире администраторов СХД это вполне естесственно и понятно.
Потомучто это два близких, но совершенно разных мира.
Вот кпримеру админы Linux могут запустить команду удаления системных файлов, обладая root правами, и вообще в этом мире действует идеология: «больше функционала», «нет ограничений у суперпользователя», «всё и сразу», «если админ делает глупости, это его проблемы».
В мире же СХД действует совсем другая идеология: максимум отказоустойчивости, безопасности и производительности, админ не может делать всё если это противоречит первым трем утверждениям. Многие веши заблокированы для админа СХД, ему не дают права «делать всё» и стараются максимум оградить от ошибок.
В мире СХД очень важно чтобы партиционирование не повлияло на производительность и безопасность, и вписалось во все уровни обеспечения отказоустойчивости СХД, по-этому партиционирование только сейчас помошло на помошь системным разделам.
С точки зрения работы с VMware NFS протокол более удобен в плане резервного копирования/восстановления, клонирования, тонкого провиженинга (Thing Provitioning) и Дедубликации в связке с СХД NetApp.
Когда хранилище отдаёт блочное устройство на котором потом живёт файловая система, а поверх неё лежат виртуалки, то СХД не знает о том что там и где на самом деле лежит. Когда же cистема хранения (не гипервизор) делает снепшоты или клоны с блочного устройства она не может отделить одни виртуальные машины от других, по-этому в снепшоте/клоне будут находиться все виртуальные машины. Если откатываться на ранее сделанный снепшот, то все данные будет откачены назад.
По-этому удобнее когда СХД управляет файловой системой и соответственно знает о том что где лежит. Когда мы делаем снепшот с файловой шары NFS, то как и в случае блочного устройства откатить мы можем только всю шару целиком, но при этом можем поштучно выборочно клонировать виртуалки средствами хранилища, не нагружая гипервизор. После снятия снепшота все виртуалки зафиксированные в снепшоте будут видны из специальной папки .snapshot в корне NFS датастора, и любая виртуальная машина может быть от туда восстановлена или скопирована просто операцией копирования.
Зачем вообще исспользовать снепшоты/клоны хранилища?
На практике использовать снепшоты/клоны NetApp очень выгодно, так как они, в отличае VMWare снепшотов, совсем никак не влияют на производительность всей системы. Напомню, что VMware не рекомендует исспользовать свои снепшоты на высоконагруженных вируальных машинах, потому что снепшоты VMWare влияют на производительность виртуальной машины потому-что работают по технологии CoW, чем больше снепшотов, тем хуже работает виртуальная машина.
ThingProvitioning / Дедубликация на хранилище
ThingProvitioning который исспользуется на СХД NetApp FAS тоже не влияет на производительность.
Когда вы исспользуете эти технологии на стороне хранилища, то высвобожденное пространство в случае NFS возращается «внутрь» файловой шары и может исспользоваться живущими на ней виртуалками, в случае блочного хранения высвобожденное какбы во вне луна (можно создать ещё один лун), а не внутрь.
Блочные протоколы FC/FCoE/iSCSI удобно исспользовать для загрузки серверов. Важным преимуществом блочных протоколов перед NFS является наличие встроенного механизма мультипасинга и балансировки нагрузки. Так как у NFS нет мультипасинга, его роль должен выполнять коммутатор и технологии на подобии vPC и LACP. Также протоколы FC/FCoE устроены таким образом, что они не теряют свои фреймы, это кстати часто является причиной более низких задержек чем у Ethernet. К счастью Nexus 5k поддерживает DCB (lossless Ethernet), vPC, LACP что позволяет полностью компенсировать все эти недостатки NFS.
И можно ли исспользовать DeviceHive с домашними контроллерами умного дома?
Из-за высокого потребления электроэнергии ESP8266 не совсем идеальное решение. Другими словами ESP8266 будет всегда исспользоваться только там, куда можно подвести питание или куда можно установить относительно крупную батарею.
И соответственно в продолжение предыдущей мысли, логично предположить, что эта проблема могла бы быть решена заменой WiFi на BLE.
Обязательным требованием по сапорту для FlexPod есть уровни сервиса не ниже Cisco SnartNet и NetApp Support Edge Premium.
Футболить между вендорами точно не смогут, для этого специально разработан механизм в рамках кооперативного сапорта.
Если к примеру кейс по нетапу застрял, то есть регламентированное время для SupportEdge когда кейс будет подниматься выше и выше доходить до уровня руководителя поддержки вплоть до вицепрезидента департамента поддержки, если он не был разрешен.
К сожалению более детально внутреннему устройство кооперативного сапорта не подскажу.
Что касается других вендоров, в том числе моно-вендоров, вы же понимаете, что к примеру сетевой отдел поддержки, отделы разнообразного софт, отделы СХД и серверов это все-равно разные отделы, разные специалисты. А все эти отделы как правило это купленные разнородные компании ныне живущие под одним брендом, так что большой разницы не вижу.
Во всех четырех тезисах первого коментария оговаривалось только про наличие проблемы, без описания как именно это сделать.
К примеру по первому и второму тезисам не говориться как именно проверять личность. Вариантов масса. К примеру паспорт или мобильный или идентификационный код или…
По третьему тезису согласен, что ответ практически очевиден. Но вообще-то можно предположить к вариант «удержался».
Под четвертым вариантом опять же нет уточнения. К примеру скрывать всех подряд или дать юзеру чек бокс с вопросом хочет ли он чтобы его ФИО небыло видно.
Относительно числа голосовавших точно также нет однозначности в оригинальном комментарии. Оговаривается проблема накрутить без уточнения способа ее решения.
Как видите я не зря переспросил автора комментария, какие конкретно, предложил бы улучшения. Так как его тезисы нуждаются в дополнении.