Комментарии 100
Я в последнее время не занимаюсь корпоративной информационной инфраструктурой и СХД в частности, но вот складывается ощущение, что вся эта сакральность СХД как невероятно отказоустойчивой, сложной и высокоэффективной штуковины осталась в прошлом.
Большинству контор, даже крупных, нахрен не сдался весь этот набор возможностей СХД EMC на пять листов (также как и большинству гос. покупателей коммутаторов и маршрутизаторов Cisco не нужно 98% их возможностей). При этом весь этот маркетинг о покупке крутого устройства, которое решит проблемы на десять лет вперёд (т.е. проблемы, которых ещё нет) уже тоже приелся.
На мой взгляд, программные решения уже вполне зрелые и надёжные, и перейти от простого iSCSI СХД на встроенном функционале Windows или Linux на одном сервере к Windows Storage Spaces на куче серверов и JBOD или чему-то ещё более сложному вообще не проблема. И такой переход будет решать реальные проблемы. Ну и дешевле будет, само собой.
Что авторы статьи думают на этот счёт?
Большинству контор, даже крупных, нахрен не сдался весь этот набор возможностей СХД EMC на пять листов (также как и большинству гос. покупателей коммутаторов и маршрутизаторов Cisco не нужно 98% их возможностей). При этом весь этот маркетинг о покупке крутого устройства, которое решит проблемы на десять лет вперёд (т.е. проблемы, которых ещё нет) уже тоже приелся.
На мой взгляд, программные решения уже вполне зрелые и надёжные, и перейти от простого iSCSI СХД на встроенном функционале Windows или Linux на одном сервере к Windows Storage Spaces на куче серверов и JBOD или чему-то ещё более сложному вообще не проблема. И такой переход будет решать реальные проблемы. Ну и дешевле будет, само собой.
Что авторы статьи думают на этот счёт?
Про Windows Storage Spaces не скажу, я его в продакшене в принципе не видел, но наверняка — какие то задачи он способен решать. В целом, если не брать самосборные серверы, то SDS не выходит дешевле классической хранилки, т.к. стоимость ПО довольно высока. По тому и бума SDS до сих пор нет (не беря в расчёт opensource, тут другая ситуация). Но опять же — всё зависит от задач. Если ваш SLA вам позволяет использовать SDS, если ваши задачи требуют высокой параллелизации, если вам не нужна функциональность СХД, почему нет?
Посчитано и внедрено — SDS Open-E JovianDSS + Supermicro выходит значительно дешевле классических хранилок. И ни в чем не уступает.
Софтовые решения дают и разноуровневое хранение и SSD кеширование и дедупликацию.
А аппаратные не дают? :)
Аппаратные дают тоже, но софт дешевле и проще в плане поднятия в случае проблем с железом (кроме проблем с накопителями). Для небольших и думаю многих средних контор это предпочтительнее решение. Софт постепенно вытесняет железные решения.
Софт постепенно вытесняет железные решения.
Статистикой поделитесь?
>Большинству контор, даже крупных, нахрен не сдался весь этот набор возможностей
Большинство контор даже не подозревает о реальных требованиях к инфраструктуре и СХД. И я значительно чаще вижу обратную ситуацию, коогда из-за непонимания реальных цифр по RPO и RTO, стоимости простоя в час, контора использует решения и архитектуры на порядок худшие, чем реально требуются.
Любые разговоры же «им все это не надо» вообще лишены смысла пока не сформулирована стоимость данных и влияние простоев и потери данных на основной бизнес.
Большинство контор даже не подозревает о реальных требованиях к инфраструктуре и СХД. И я значительно чаще вижу обратную ситуацию, коогда из-за непонимания реальных цифр по RPO и RTO, стоимости простоя в час, контора использует решения и архитектуры на порядок худшие, чем реально требуются.
Любые разговоры же «им все это не надо» вообще лишены смысла пока не сформулирована стоимость данных и влияние простоев и потери данных на основной бизнес.
Вот эти-то сложновысчитываемые характеристики меня и смущают (RPO, RTO и пр.)
Давайте рассмотрим конкретный пример. Когда-то я участвовал в модернизации (читай создании) ЦОД для одной из крупнейших и авторитетнейших госструктур. Вы, конечно, знаете, но для тех кто не в курсе, скажу, что именно государство в России является основным покупателем СХД. Некоторые крупнейшие вендоры первые годы жили только! за счёт госзаказов от какого-нибудь РЖД. Тоже факт из первых рук, если что.
Так вот, большая госструктура. Каков у неё стоимость простоя в час? Да кто же знает? Это же не коммерческая компания. Но не это главное, суть в следующем.
Поставили мы им СХД за сумму порядка миллиона долларов, подключили к корзинкам с серверами по 10GB FCoE (или iSCSI — не помню). На серверах VMware vSphere. Всё работает, всё хорошо.
Проходит время и диски начинают сыпаться, они же там обычные, что бы и кто не говорил про «доработку прошивок», «дополнительное тестирование» и пр. И в какой-то момент вендор говорит: «Ребята, вы под санкциями, менять диски не можем!». А купить при наличии гарантии не так просто.
Так чего же делала эта СХД за бешеные деньги — то же что и 99% СХД — обслуживала кластер виртуализации. Всё, что её отличало от самосбора в этом смысле — два независимых контроллера. Хотя и самосбор может иметь сколько угодно путей просто добавив сетевые интерфейсы.
Так что я не к тому, что СХД надо срочно заменить на SuperMicro + CentOS + tgtd. Я про то, что представление о корпоративном ИТ всё же меняется и зачастую такая замена уже уместна. Также как и использование публичных облаков, что в первые годы их продвижения казалось скорее экзотикой.
Давайте рассмотрим конкретный пример. Когда-то я участвовал в модернизации (читай создании) ЦОД для одной из крупнейших и авторитетнейших госструктур. Вы, конечно, знаете, но для тех кто не в курсе, скажу, что именно государство в России является основным покупателем СХД. Некоторые крупнейшие вендоры первые годы жили только! за счёт госзаказов от какого-нибудь РЖД. Тоже факт из первых рук, если что.
Так вот, большая госструктура. Каков у неё стоимость простоя в час? Да кто же знает? Это же не коммерческая компания. Но не это главное, суть в следующем.
Поставили мы им СХД за сумму порядка миллиона долларов, подключили к корзинкам с серверами по 10GB FCoE (или iSCSI — не помню). На серверах VMware vSphere. Всё работает, всё хорошо.
Проходит время и диски начинают сыпаться, они же там обычные, что бы и кто не говорил про «доработку прошивок», «дополнительное тестирование» и пр. И в какой-то момент вендор говорит: «Ребята, вы под санкциями, менять диски не можем!». А купить при наличии гарантии не так просто.
Так чего же делала эта СХД за бешеные деньги — то же что и 99% СХД — обслуживала кластер виртуализации. Всё, что её отличало от самосбора в этом смысле — два независимых контроллера. Хотя и самосбор может иметь сколько угодно путей просто добавив сетевые интерфейсы.
Так что я не к тому, что СХД надо срочно заменить на SuperMicro + CentOS + tgtd. Я про то, что представление о корпоративном ИТ всё же меняется и зачастую такая замена уже уместна. Также как и использование публичных облаков, что в первые годы их продвижения казалось скорее экзотикой.
Давайте разберем потезисно.
RPO / RTO — это не сложновысчитываемые характеристики, а всего лишь целевые показатели доступности сервисов, которые ДОЛЖНЫ присутствовать в техническом задании на проектирование.
Проектирование любой инфраструктуры без данных показателей — это шаманство, а не инженерная работа.
На практике получается совсем нелегко добыть от бизнес-подразделений показатели руб/час по простою и потере данных, из которых мы конечно получаем экономическое обоснование той или иной технологии в архитектуре инфраструктуры, или непосредственно сами RPO / RTO. Но это говорит лишь о слабости и незрелости менеджмента в целом. Никакой связи с безграмотностью проектировщика или его отношением к проектированию.
«Всего лишь обслуживала кластер виртуализации». Обслуживание кластера виртуализации — это предоставление пространства хранения данных с заданными / удовлетворяющими показателями производительности и надежности. При этом можно использовать весь набор технологий — репликацию (с управлением через средства гипервизоров, в данном случае SRM), снапшоты, QoS для выделенных под нагруженные сервисы отдельных томов, журналирование и так далее.
То, что хранилка за миллион долларов была тупой дисковой полкой с двумя контроллерами — это фейл, извините, вашего проектирования. Или попросту освоение бюджета.
RPO / RTO — это не сложновысчитываемые характеристики, а всего лишь целевые показатели доступности сервисов, которые ДОЛЖНЫ присутствовать в техническом задании на проектирование.
Проектирование любой инфраструктуры без данных показателей — это шаманство, а не инженерная работа.
На практике получается совсем нелегко добыть от бизнес-подразделений показатели руб/час по простою и потере данных, из которых мы конечно получаем экономическое обоснование той или иной технологии в архитектуре инфраструктуры, или непосредственно сами RPO / RTO. Но это говорит лишь о слабости и незрелости менеджмента в целом. Никакой связи с безграмотностью проектировщика или его отношением к проектированию.
«Всего лишь обслуживала кластер виртуализации». Обслуживание кластера виртуализации — это предоставление пространства хранения данных с заданными / удовлетворяющими показателями производительности и надежности. При этом можно использовать весь набор технологий — репликацию (с управлением через средства гипервизоров, в данном случае SRM), снапшоты, QoS для выделенных под нагруженные сервисы отдельных томов, журналирование и так далее.
То, что хранилка за миллион долларов была тупой дисковой полкой с двумя контроллерами — это фейл, извините, вашего проектирования. Или попросту освоение бюджета.
ОК, я вас понял. В вашей деятельности, судя по всему, возможно посчитать текущие и примерные будущие потребности, сравнить предложения на рынке и выбрать оптимальный вариант. При этом обосновав выбор с экономической точки зрения и увязав его с ИТ-стратегией, которая основана на бизнес-стратегии.
Мне же не так повезло. Мне приходилось прикидывать «на глаз» что есть сейчас и что будет. Выбирать из одного вендора (потому что другие не подходят). Экономические обоснования всегда должны быть в рамках бюджета. Да и вообще — заказчик как правило был из госсектора (хотя и не всегда), где понятие стоимости простоя в рублях вызовет тяжёлое недоумение (представьте, к примеру, Ген. прокуратуру). Ну и ТЗ и прочее писалось со стороны — пообщаться с бизнес-пользователями, поинтересоваться планами развития ИТ и будущими потребностями было просто не у кого или нельзя.
Вот мне почему-то кажется, что мой случай несколько чаще встречается на практике чем ваш. А может и нет, может просто так сложилось.
Мне же не так повезло. Мне приходилось прикидывать «на глаз» что есть сейчас и что будет. Выбирать из одного вендора (потому что другие не подходят). Экономические обоснования всегда должны быть в рамках бюджета. Да и вообще — заказчик как правило был из госсектора (хотя и не всегда), где понятие стоимости простоя в рублях вызовет тяжёлое недоумение (представьте, к примеру, Ген. прокуратуру). Ну и ТЗ и прочее писалось со стороны — пообщаться с бизнес-пользователями, поинтересоваться планами развития ИТ и будущими потребностями было просто не у кого или нельзя.
Вот мне почему-то кажется, что мой случай несколько чаще встречается на практике чем ваш. А может и нет, может просто так сложилось.
Сервера редко работают в вакууме и сами на себя, обеспечивают неких информационных систем обеспечивающих выполнение процессов. Ну а дальше определяем критичность процесса, его влияние на выполняемые организацией функции, от этого и стоит исходить.
В самом простом варианте, можно посчитать на сколько увеличится трудоемкость выполняемых процессов и определить стоимость простоя как суммарное увеличение трудоемкости (и стоимости соответственно). Не правильно и очень грубо, но вполне возможно.
В самом простом варианте, можно посчитать на сколько увеличится трудоемкость выполняемых процессов и определить стоимость простоя как суммарное увеличение трудоемкости (и стоимости соответственно). Не правильно и очень грубо, но вполне возможно.
SDS имеет свою нишу и далеко не везде применим
Открою секрет. Абсолютное большинство современных классических СХД — это стандартные x86 серверы без какого либо специального аппаратного обеспечения. Вся логика реализована в софте, т.е. фактически это SDS.
Одним из мамонтов пока остается HPE 3Par, в котором используются ASICи.
Одним из мамонтов пока остается HPE 3Par, в котором используются ASICи.
Мелким компаниям из 15 сотрудников, может и нужно, но здесь вопрос не в том что хотелось бы, а в том что у таких компаний денег на это нет. По этому такие комапнии выкручиваются самосбором а-ля Windows File Server или Linux NFS. И такой подход приемлем и скорее всего даже бизес-обоснован для таких компаний.
Но не нужно пытаться натянуть мартышку на глобус, для больших компаний этот же подход просто не катит.
А вот огромные клауд-провайдеры а-ля AWS/Azure/Google/Alibaba/IBM могут себе позволить это держать на самосборе. Но даже они не могут покрыть все портебности бизнеса в системах хранения, собственно по этому вендоры появляются как услуга в этих гигантах со своими железяками и софтом. Потому что десятки лет опыта, интеграцию и экосистему, не пропьёшь.
Но не нужно пытаться натянуть мартышку на глобус, для больших компаний этот же подход просто не катит.
А вот огромные клауд-провайдеры а-ля AWS/Azure/Google/Alibaba/IBM могут себе позволить это держать на самосборе. Но даже они не могут покрыть все портебности бизнеса в системах хранения, собственно по этому вендоры появляются как услуга в этих гигантах со своими железяками и софтом. Потому что десятки лет опыта, интеграцию и экосистему, не пропьёшь.
>а в том что у таких компаний денег на это нет.
Нет денег на что? на ЭТО?
ИТ на сегодня — это часть средств производства. В рамках ИТ оборудования есть система хранения данных. Стоимость покупки средств производства (CapEx) и обслуживания средств производства (OpEx) учитываются при продаже продуктов / услуг.
Далее мы рассматриваем влияние доступности / качества средств производства на само производство. Если встанет станок, то как это повлияет на деятельность компании? Если будет утерян годовой отчет, или полностью будет утеряна 1С: Склад, то как это повиляет на деятельность компании?
«Денег нет» — это неверная фраза, верная будет звучать так: «ты, как ответственный за ИТ системы, не предоставил мне, ответственного за финансы, ИТ-риски и влияние их на основную деятельность компании, а я не заложил это в бюджет». Об этом я тоже не раз писал.
www.beerpanda.ru/?p=176
И да, если влияние ИТ систем и в частности СХД на компанию низкое и компания может спокойно простоять дня три без СХД, то выбор SOHO системы или самосбор вполне обоснованный и правильный. Но сначала надо посчитать.
Нет денег на что? на ЭТО?
ИТ на сегодня — это часть средств производства. В рамках ИТ оборудования есть система хранения данных. Стоимость покупки средств производства (CapEx) и обслуживания средств производства (OpEx) учитываются при продаже продуктов / услуг.
Далее мы рассматриваем влияние доступности / качества средств производства на само производство. Если встанет станок, то как это повлияет на деятельность компании? Если будет утерян годовой отчет, или полностью будет утеряна 1С: Склад, то как это повиляет на деятельность компании?
«Денег нет» — это неверная фраза, верная будет звучать так: «ты, как ответственный за ИТ системы, не предоставил мне, ответственного за финансы, ИТ-риски и влияние их на основную деятельность компании, а я не заложил это в бюджет». Об этом я тоже не раз писал.
www.beerpanda.ru/?p=176
И да, если влияние ИТ систем и в частности СХД на компанию низкое и компания может спокойно простоять дня три без СХД, то выбор SOHO системы или самосбор вполне обоснованный и правильный. Но сначала надо посчитать.
хитро спрятана проблема NVMe
сейчас один такой диск иногда может больше, чем дорогущая полка из-за устаревших интерфейсов (точнее их пропускной способности)
сейчас один такой диск иногда может больше, чем дорогущая полка из-за устаревших интерфейсов (точнее их пропускной способности)
а точнее протокола…
хитро спрятана проблема NVMe
А в чё собственно проблема NVMe? В том, что не все вендоры к нему уже готовы?
NetApp сейчас, пожалуй, лидер в этом направлении, так в «Full NVMe» массиве AFF A320 полки подключаются через 100GbE через RoCE, к примеру.
Я скажу более, даже SATA SSD зачастую может больше, чем выдает полка. Ввиду расстояния до данных.
Но проблема одиночного диска в его:
1. Надежности. Умрет диск — пропадут данные
2. Монопольном доступе. С диском может работать только система, в которую он физически включен.
Но проблема одиночного диска в его:
1. Надежности. Умрет диск — пропадут данные
2. Монопольном доступе. С диском может работать только система, в которую он физически включен.
Ключевое слово — «иногда». Не все проблемы можно решить, воткнув NVMe диск в сервер.
Зачем сложный и некрасивый RRDtool, когда есть прекрасный DPACK?
Только сегодня его развернул «на посмотреть» :)
Ну он уже давно LiveOptics, но картинки рисует красивые и информативные :)
А можно подробнее, что прекрасного в DPACK? Кроме красивых картинок, которые можно с умным видом показывать начальству или заказчику? По мне так утилита от уважаемого вендора, которая не умеет анализировать уже собранные performance логи с его же вендорских СХД выглядит мягко говоря странным поделием. Если проблемы с производительностью у меня были «вчера», то чем мне поможет DPACK «сегодня»? :). Это не говоря уже про СХД сторонних вендоров.
DPACK не для анализа проблем, котрые были вчера. Это инструмент, который позволяет понять текущее состояние, а дальше уже решать, что с этим делать. Чаще всего его используют для сбора статистики для последующего сайзинга нового решения.
Таки уважаемый вендор совсем не под этим соусом подает его партнерам и заказчикам :), скорее как серебряную пулю. Т.е. по факту DPACK в лучшем случае подходит для того, что бы сильно на глазок прикинуть текущую нагрузку заказчика со стороны серверов (и только некоторых СХД уважаемого вендора) и не более того :). При этом вендор отказался от Mitrend, который выглядел куда как интереснее и умеет намного больше и лучше чем DPACK (в то время даже не знавший, что в природе существует еще что-то кроме серверов) :).
Ну тогда это вопрос к вендору. Я DPACK как раз воспринимаю как инструмнет для "прикидывания на глазок".
Собственно к тому почему DPACK вдруг "на глазок". Мне не очень понятен например смысл тратить 3 дня или неделю на снятие данных о производительности систем заказчика в реальном времени в случаях, когда на СХД уже присутствует готовая статистика на 90 дней назад. Но DPACK с ней работать почему-то не научили. Проблема тут только в том, что статистика эта для простых смертных доступна только при прямом подключении в интерфейс управления СХД, а для пресейлинга это как раз не назвать удобным.
Он простой, наглядный и его формат понимают сайзеры других вендоров.
А для анализа производительности есть бесплатные утилиты от производителей СХД, тот же OCUM или Cloud Insights.
А для анализа производительности есть бесплатные утилиты от производителей СХД, тот же OCUM или Cloud Insights.
Странная статья. Половина макетинговый булшит — половина оооочень общие слова.
Где хоть слово про типы нагрузки? (OLTP/dwh)
Где рассказ про iops/latency/bandwidthи их зависимость?
Мне кажется те, кто в теме знают что делать и без таких статей. Те, кто не в курсе после этой статьи будут еще более не в курсе.
Лучше пойти к 2-3 вендорам и поговорить с их пресейлами и сравнить показания — пользы будет больше
Где хоть слово про типы нагрузки? (OLTP/dwh)
Где рассказ про iops/latency/bandwidthи их зависимость?
Мне кажется те, кто в теме знают что делать и без таких статей. Те, кто не в курсе после этой статьи будут еще более не в курсе.
Лучше пойти к 2-3 вендорам и поговорить с их пресейлами и сравнить показания — пользы будет больше
НЛО прилетело и опубликовало эту надпись здесь
Лучше пойти к 2-3 вендорам и поговорить с их пресейлами и сравнить показания
Собрались американец, русский и француз, и говорят по-китайски…
Сколько раз было — закидываешь вендору спеку — столько то iops, под такие то задачи, такой объём… один на флеше считает, второй на гибриде — какой пользы тут будет лучше?
Ну мне один очень опытный пресейл по СХД в крупном вендоре не смог посчитать на бумаге с калькулятором набивку СХД по дискам под заданные IOPS потому что не знал что такое RAID Penalty.
А ты говоришь флэш, гибрид…
А ты говоришь флэш, гибрид…
Где это такое доброе начальство?
А вы в курсе что в некоторых схд их нет? Ну просто в силу архитектуры =) ну или настолько малы что ими можно пренебречь
в некоторых
Давайте пересчитаем их по пальцам :)
Тут скорее проблема не в том что они есть или нет, а в том что технический специалист должен это в принципе знать (как минимум в рамках конкурентного анализа) и учитывать как этот (если есть), так и другие факторы (garbage collection, например) при расчетах
Полтора года назад покупали СХД, All-flash, выбирали из трех брендов (не буду перечислять чтобы не было рекламы/антирекламы) «высшего» дивизиона.
Спеки урегулировались не один месяц, и было большой проблемой даже привести их к более-менее одинаковым показателям… Например, у одного вендора дополнительные диски можно втыкать по одному а у другого только пару, или у одного емкость дисков / полки больше чем у другого и там надо докупать еще одну полку (цена растет) и т.д.
В итоге вопрос выбора вендора — это не простой процесс.
Спеки урегулировались не один месяц, и было большой проблемой даже привести их к более-менее одинаковым показателям… Например, у одного вендора дополнительные диски можно втыкать по одному а у другого только пару, или у одного емкость дисков / полки больше чем у другого и там надо докупать еще одну полку (цена растет) и т.д.
В итоге вопрос выбора вендора — это не простой процесс.
Я нигде не говорил, что это простой процесс. Но до выбора конкретной модели конкретного вендора надо сформулировать — а что же собственно мы хотим от этой системы хранения.
Потому что надо выбирать не по одинаковому количеств удисков, а по требуемым показателям производительности, наджености и функциональности. Каждый вендор может выполнить это требования, используя разные технологии и разное количество дисков.
Ну про прописные истины тут не надо, естественно во главу угла ставились показатели производительности, надежность, поддержка и прочее.
Но чтобы просто сравнить спеки, привести их к более-менее одинаковым характеристикам — надо попотеть… а потом оказывается что один вендор конкретно дороже из-за таких вот особенностей.
Но чтобы просто сравнить спеки, привести их к более-менее одинаковым характеристикам — надо попотеть… а потом оказывается что один вендор конкретно дороже из-за таких вот особенностей.
>Где хоть слово про типы нагрузки? (OLTP/dwh)
>Где рассказ про iops/latency/bandwidthи их зависимость?
Вероятно ждут вашего пера. Цель данной статьи не включала данную тематику.
>Где рассказ про iops/latency/bandwidthи их зависимость?
Вероятно ждут вашего пера. Цель данной статьи не включала данную тематику.
Простите пожалуйста, а как вы предлагаете выбирать схд без этой информации? По цвету лампочек на передней панели? Если уж взялись писать статью о том как выбрать схд, так опишите основы хотя бы.
Смотрите какая у вас прекрасная возможность причинить ИТ сообществу добро и нанести непоправимую пользу.
Напишите замечательную статью как выбирать СХД правильно. Со всеми подробностями, включая общую теорию проведения пилотного тестирования, генерации нагрузки, правильной трактовки результатов. Судя по вашим комментариям, вы являетесь в этом несомненным специалистом. Почту за честь учиться общей теории СХД по вашим статьям.
Напишите замечательную статью как выбирать СХД правильно. Со всеми подробностями, включая общую теорию проведения пилотного тестирования, генерации нагрузки, правильной трактовки результатов. Судя по вашим комментариям, вы являетесь в этом несомненным специалистом. Почту за честь учиться общей теории СХД по вашим статьям.
Не возьмусь, ибо никогда не закончу. Это очень обширная тема, с кучей нюансов и подводных камней. Но вы решили что сможете — теперь получаете обратную связь. Я ж не виноват что вы в своей статье упустили огромные очевидные куски.
С точки зрения читателя, у меня есть прекрасная статья от Антона и эээ ничего от доктора. Кто из вас мне больше полезен?
Нет ничего плохого, чтобы спросить у автора о пропусках. Отличный ответ, что это за рамками данного материала. А вот дальнейшее нытье что все плохо, но сам не дам… Это не достойно профессионала.
В статье нет половины важных вещей, которые действительно нужны для подбора СХД. В итоге человек сделавший выбор на основании этих данных сделает заранее неверный выбор из-за отсутствия важной информации по теме. И вы считаете что это действительно полезная статья?
Простой пример — у вас нагрузка OLTP, и вы решаете по статье сделать все на базе iscsi (там же написано что это тоже самое что и fc). При этом для экономии вы скорее всего пустите данные по тем же свичам, что и общий трафик (хорошо если в разных vlan-ах). И тут кто-то решил себе на вечер скачать фильм, или просто воткнули в сеть кривой принтер — и вот уже ваша OLTP база офигевает от задержек в пару секунд на запись/чтение, вас натягивают как сову на глобус у начальства.
Статья под таким названием скорее вредная, чем полезная. Жаль что вы этого не понимаете
Простой пример — у вас нагрузка OLTP, и вы решаете по статье сделать все на базе iscsi (там же написано что это тоже самое что и fc). При этом для экономии вы скорее всего пустите данные по тем же свичам, что и общий трафик (хорошо если в разных vlan-ах). И тут кто-то решил себе на вечер скачать фильм, или просто воткнули в сеть кривой принтер — и вот уже ваша OLTP база офигевает от задержек в пару секунд на запись/чтение, вас натягивают как сову на глобус у начальства.
Статья под таким названием скорее вредная, чем полезная. Жаль что вы этого не понимаете
Я правильно понимаю, что в данном случае вы описываете свой печальный опыт?
О том как вы пустили все по одним свитчам в одном VLAN и как у вас в офисе народ качает на вечер фильмы и в итоге лежит ваша 1С, а потом вас натягивают как сову на глобус?
О том как вы пустили все по одним свитчам в одном VLAN и как у вас в офисе народ качает на вечер фильмы и в итоге лежит ваша 1С, а потом вас натягивают как сову на глобус?
Нет, это я описываю опыт людей, которые руководствовались как раз такого рода статьями. А мне нужно было привести это в божеский вид (и привел).
Что то мне подсказывает, что человек, делающий такое, никакими статьями и учебниками не руководствуется.
Но вернемся к вопросу — вы вольны написать правильную статью. Займет у вас не сильно больше времени, чем написание вот всех этих обличительных комментариев.
И есть еще одно подозрение — что после статьи такого уровня у вас сменится работа и вырастет зарплата
Но вернемся к вопросу — вы вольны написать правильную статью. Займет у вас не сильно больше времени, чем написание вот всех этих обличительных комментариев.
И есть еще одно подозрение — что после статьи такого уровня у вас сменится работа и вырастет зарплата
И есть еще одно подозрение — что после статьи такого уровня у вас сменится работа и вырастет зарплата
=) посмеялся
Но вернемся к вопросу — вы вольны написать правильную статью. Займет у вас не сильно больше времени, чем написание вот всех этих обличительных комментариев.
печально что вы не слышите что вам говорят — это большая целая статей, в которые должны входить основы хотя бы:
Теория (3-5 статей статьи):
- физическая теория (диски/рейды/iops/latency и тому подобное)
- теория про нагрузки и какие они бывают
- блочный/файловый доступы
- построения san-сетей
"Практика" (еще не понятно сколько статей):
- что такое классические san-сети и как с этим жить
- что такое sds и как с этим жить
- сравнение когда что более уместно
- высокая доступность
- высокие нагрузки
И это то, о чем я сходу подумал. А есть еще тысячи моментов которые всплывут во время написания.
По сути все эти выборы сводятся к шутке с баша — "какой лучше дистрибутив Linux выбрать? Тот, который стоит у твоего знакомого админа"
Займет у вас не сильно больше времени, чем написание вот всех этих обличительных комментариев.
Каждая статья это примерно 3-5 дней плотной работы (актуализировать знания, подобрать пруфы, само написание). В итоге это реально месяцы работы и на выходе по сути просто книжка. И вы реально считаете что я трачу столько на комментарии?
При этом для экономии вы скорее всего пустите данные по тем же свичам, что и общий трафик
Давайте будем честными — это не проблема выбора СХД, а полное отсутствие компетенции у человека, который этим занимается. Тут ни одна статья не поможет.
Ну смотрите — статья называется «Как выбрать СХД, не выстрелив себе в ногу». Там есть много действительно полезной информации для людей которые впервые столкнулись с этой проблемой, но совершенно нет базовых вещей. Мне вот всегда казалось что идти надо от задачи, а это тут как-то не очевидно описано.
Теорию струн бесполезно рассказывать людям у которых нет соответствующей базы для понимания.
Теорию струн бесполезно рассказывать людям у которых нет соответствующей базы для понимания.
Так в том то и дело, что в статье «Как выбрать СХД" описывается — как выбрать СХД, а не построить всю инфраструктуру или SAN. Естественно в рамках одной статьи — физически невозможно рассказать всё. Тут уже надо не статью, а книгу тогда писать, от и до. В конце-концов, никто не же мешает кому то, считая, что какая то часть темы не рассказана должным образом — написать статью самому. Опять-таки для нас, камменты это то же повод посмотреть — что хотят люди, получить фидбек и возможно потом написать ещё.
Завалить свич скачкой фильма? У вас свичи 10 мегабитные? ЧП могут быть, но такое подключение имеет иногда и плюсы.
Именно из-за таких вот комментариев я и перестал писать свои статьи на хабре.
А вот попробуйте сами что-то написать. Прийдут такие же как вы и спасибо не скажут.
А вот попробуйте сами что-то написать. Прийдут такие же как вы и спасибо не скажут.
Антон, вполне занимательная статья для общего развития. Спасибо! Мне казалось ты ушел в воинствующего HCI вендора (возможно ошибался), где все приходящие немедленно становяться адептами нового учения :). Рад что с тобой такого не произошло и здравый взгляд на вещи ни куда не делся.
Во первых «вендор» вообще не воинствующий. То что в нем работает и пишет по русски ровно один такой человек не значит, что «вендор воинствующий». Это индивидуальный стиль одного человека. Сейчас в России работает у вендора _семь_ человек, и никто из них не «воинствующий».
Во вторых, статья принципиально задумывалась про классические СХД, здесь намеренно ни одно HCI решение не упомянуто.
Во вторых, статья принципиально задумывалась про классические СХД, здесь намеренно ни одно HCI решение не упомянуто.
«удаляющее кодирование», тут, видимо, речь про другой устойчивый термин «помехоустойчивое кодирование» (erasure coding)?
Да, верно. В процессе просто автоматом всплыл откуда то неверный перевод. И как уже было отмечено, по нему ничего не было написано, поскольку фактически в классических внешних СХД оно реализовано в виде RAID, и является основой работы.
Непосредственно как фишка erasure coding именно под таким названием применяется только в гиперконвергентных системах, поэтому я просто убрал его из заголовка. Поскольку гиперконвергенцию в рамках данной статьи мы не рассматриваем от слова совсем.
Непосредственно как фишка erasure coding именно под таким названием применяется только в гиперконвергентных системах, поэтому я просто убрал его из заголовка. Поскольку гиперконвергенцию в рамках данной статьи мы не рассматриваем от слова совсем.
В классических erasure coding не используется, но применяется он и не только в гиперконвергентных системах. Есть еще горизонтально масштабируемые системы хранения, которые не являются гиперконвергентными и появились за долго до них. Isilon, HydraStor, Elastic Cloud Storage и возможно еще какие-то похожие по принципам защиты данных решения.
Добавлю к списку еще несколько вариантов реализации объектных СХД: Scality, Cleversafe. Да, у систем своя ниша, принцип работы: данные воспринимаются как объекты, каждая порция со своим хэш адресом, по которому происходит поиск уже записанной информации. Из интересного — Erasure Coding в объектных СХД эта одна из реализаций подхода к избыточности имени Reed-Solomon'а, тот же подход к устройству избыточности и принципу разбиения всего поступающего набора данных, с некими изменениями, применяется в технологии RAID 6. Теория разработана еще в 1960г. :)
Открываем https://en.wikipedia.org/wiki/Erasure_code
Optimal erasure codes
Parity: used in RAID storage systems.
Optimal erasure codes
Parity: used in RAID storage systems.
По-русски это " кодирование с избыточностью"
Можно еще к выводу: тестируйте свои реальные данные на СХД перед покупкой. Некоторые маркетинговые «фичи» работают только в узком диапазоне данных и смотрите «наперед»: то, что важно сегодня (объем, скорость, функционал) слабо коррелируется с тем набором данных, который будет на ваших СХД через 2-3 года.
Как-то вы очень цеф обидели.
Чем? Все кто с ним плотно работал всё это знают )
В посте ceph упоминается только в фразе про "наколенные изделия".
Ну они такими и являются. Коммерческих решений на Ceph либо нет, либо поставляются с отказом от ответственности.
Если зрелые системы SDS на базе устоявшихся платформ периодически оформляются в виде коммерческих продуктов как например:
ZFS
— Nexenta
— Open-E
— Raidix
— etc.
Lustre
— DDN
— Supermicro
— Hitachi
— HPE
— etc.
Scality
— HPE
— DELL
WEKA.IO
— HPE
— DELL
— Supermicro
То Ceph на сколько я знаю никто не продает как продукт с поддержкой. Потому что на коленке и сырой.
Если зрелые системы SDS на базе устоявшихся платформ периодически оформляются в виде коммерческих продуктов как например:
ZFS
— Nexenta
— Open-E
— Raidix
— etc.
Lustre
— DDN
— Supermicro
— Hitachi
— HPE
— etc.
Scality
— HPE
— DELL
WEKA.IO
— HPE
— DELL
— Supermicro
То Ceph на сколько я знаю никто не продает как продукт с поддержкой. Потому что на коленке и сырой.
Э… Вы когда-нибудь слышали о компании Red Hat? И что они шипят RH Storage с цефом внутри? А уж сколько они за саппорт берут...
Алсо, я хочу с интересом послушать про вендора, который готов взять полную ответственность за баги и их последствия.
После покупки RedHat IBMом, последний прекратил поддержку ряда продуктов, в частности коммерческого ceph, он сейчас передан комьюнити, новых продаж с поддержкой не будет.
Red Hat Ceph Storage не просто продаётся (Сбербанк недавно купил подписок на пару миллионов баксов), но и заменит Gluster в OpenShift 4.2.
Проще ответить чего Сбербанк не купил. Наличие чего либо в Сбербанке и РЖД не является подтверждением стабильности или качества.
Мой комментарий не про качество, а что Ceph ещё продают и покупают. Впрочем, неизвестно сколько это будет продолжаться.
В случае Сбера/РЖД лучше смотреть, что компания докупает — это значит, что пилот прошёл успешно, технология используется и пора расширяться.
RAIDIX не на базе ZFS, а со своими алгоритмами рейдов и менеджером томов.
А что значит СХД? Вообще то, слово на "Х" понял, а все вместе?
Спасибо за полезную статью!
На своем опыте могу сказать одно — СХД может появиться в компании при определенном уровне развития и зрелости.
Для меня СХД — это как минимум два блока питания, два контроллера)
На своем опыте могу сказать одно — СХД может появиться в компании при определенном уровне развития и зрелости.
Для меня СХД — это как минимум два блока питания, два контроллера)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Как выбрать СХД, не выстрелив себе в ногу