Открытое обсуждение темы «Оценка надежности дата-центров и ИТ оборудования, в частности»

Вчера прошел круглый стол по теме ЦОДов, проведенной C-News. Было обсуждено и поднято много интересных тем. Однако время на круглых столах и конференциях ограничена и всегда есть то, что Вы бы хотели обсудить. Поэтому открывается новый раздел на сайте «открытое обсуждение», где Вы можете поднять наболевшую тему или написать в уже сформированную.

Вы можете писать вопросы, комментарии, делиться своими идеями и данными, приводить примеры из жизни практики и т.д. То есть форма общения свободная в рамках, естественно, в корректной и вежливой форме, с уважением мнения друг друга. Вполне возможно, что общими усилиями мы наконец-то начнем реально обсуждать непростые вопросы. Ведь одна голова хорошо, а 100, 200 и 1000 гораздо лучше.

     Ко мне после выступления на круглом столе подошел Дмитрий Аверьянов с вопросами по поводу оценки надежности дата-центров и в частности оценки надежности кластерных системы, ИТ оборудования. Эта тема беспокоит многих, поэтому эта тема открывается для всех желающих выступить и обсудить вопросы, которые поднимает Дмитрий. Читаем и обсуждаем письмо Дмитрия, которое с его разрешения письмо вынесено на страницы сайта.

Тема оценки надежности ЦОД

При упоминании «ЦОД» — во главу угла ставится вопросы его надежности и эффективности. «Полное дублирование», «пять девяток», работа в «режиме 24/7" и т.п. Одновременно, как оказалось, вопрос надежности ЦОД – малоизученный настолько, что фактически невозможно его количественно обосновать.

Проблема Основная – методика оценки и расчета надежности ЦОД и ИТ оборудования

1. Не будем ставить под сомнение наработку на отказ (MTBF) отдельных компонентов ЦОД. Хотя она также существенно завышена и по-хорошему, должна браться не у производителя, а у независимых лабораторий.

Основной стратегией повышения надежности ЦОД – это метод поэлементного резервирования (структурного резервирования), так как только он обеспечивает желаемые четыре или пять девяток коэффициента готовности. Однако кроме самой необходимости резервирования в ЦОД, причем только для инженерной инфраструктуры, аптайм институт ничего не говорит.

 

2. Нет ни признанных ни хотя бы опубликованных моделей или методик расчета надежности резервируемых структур применительно к ЦОД или ИТ в целом: резервных ЦОД, вычислительных кластеров (в том числе гео-кластеров), СХД, телекоммуникационного оборудования. Компании производители кластеров и СХД не показывают свои модели. Более того, вендоры и заказчики скрывают отказы и простои: какой, например, банк будет говорить об этом, подвергая риску свою репутацию?

 

3. Вендоры часто ссылаются на статистику отказов. При этом, указав «пять или шесть девяток» на только что вышедшую модель, не моргнув глазом, говорят, что цифра взята «По-аналогии» с предшествующими системами, тестируемыми десятилетиями и показавшими превосходную надежность !? При этом все равно исходную статистику и рабочие журналы никто не покажет.

 

4. Отсутствие нормирующих и руководящих документов или хотя бы обсуждаемых моделей приводит к следующему. Слева кладется ТЗ с заявленными заказчиком требованиями к надежности проектируемой системы. Справа стопка справочников надежности с формулами расчета последовательно-параллельных структур (справочники, как правило, 70—х годов издания, т.к. сегодня это уже «не популярная» тема). В середине проектировщик раскладывает «удобные» модели, обеспечивающие стыковку правой и левой части. Причем выбор модели ничем не регламентирован: ни ITIL, ни TIA-942, ни другие признанные руководства и правила не дают указаний и разъяснений как нужно считать.

 

В итоге, все цифры по надежности ЦОД и его компонентов получены по принципу: «Неважно как голосуют, важно как считают», а сами расчеты больше похожи не на математические операции, а на карточные фокусы.

 

5. Может я сгущаю краски и все не так уж плохо? Если Вам известны какие-либо источники, подходы к решению этой проблемы или просто мысли на сей счет – просьба поделиться. Вместе мы возможно сможем собрать информацию.

 

Кроме того, если есть возможность, подскажите ссылки в ITIL или других источниках, где хоть как то, хоть «по-касательной» затрагивается проблема количественной оценки надежности в ЦОД или ИТ, в частности. Может что-то есть у кого-то по оценке и расчету надежности кластеров?

Оценка катастрофоустойчивости

Известны ли Вам подходы к оценки катастрофоустойчивости? Это уже несколько другие расчеты и количественная оценка требует иных подходов. В том числе, оценку наступления тех или иных катастроф, чрезвычайных ситуаций?

Российская проблема и как оценить такие риски

Какой бы надежностью не обладал бы ЦОД, хоть десять девяток, но против российской действительности он будет беспомощен и клиенты могут легко остаться без сервисов (и никакое SLA не поможет). Придут «люди в черном» из налоговой (ОНП), ОБЭП, отделов «К» или «Р», из ФСБ и т.п. и изымут сервера, например, по доносу конкурента о контрафактном ПО.

Вопросы:

А) можете ли привести примеры остановки ЦОД по наездам правоохранительных структур;

Б) как можно это качественно или количественно оценить, посчитать вероятность этих рисков?

Все риски ведь должны иметь количественную оценку и надежность должна быть исчисляемой!


Поделиться информацией

Вы можете послать эту статью или новость коллеге или знакомому по email со своим комментарием, пригласить обсудить ее. Просто нажмите на иконку конверта --->  


Сообщения, вопросы и ответы

Вы можете задать вопрос, написать комментарий, обсудить данную новость или статью.

Ваш ответ на сообщение выше

  1. Дмитрий Мацкевич 11.04.2010 в 23:03

    Дмитрий, добрый вечер,

    Спасибо за Ваши интересные вопросы

    К сожалению, я пока не встречал ни в литературе, ни в интернет методики оценки надежности ЦОД или хотя бы оценки надежности работы одной системы.

    По поводу тезиса риски должны иметь количественную оценку и надежность должна быть исчесляемой.

    Я не соглашусь с этим утверждением по одной просто причине.

    Слишком сложная получается модель.

    Большое количество элементов, влиящих друг на друга.

    Также существуют различные внешние возмущающие воздействия на систему, которые по идее тоже надо оценивать — одно дело например электрическая система в городе Х, другое в городе Y, человеческий фактор, который вообще не поддается оценке, ну и действия различных органов.

    Получается, что можно только основываться на статистических данных и делать какие-то реперные точки, что и сделал UpTime Institute

    Но он это сделал на оснвое полученных данных от американских дата-центров.

    Если появится инфомация у меня, то обязательно напишу

    С Ув.Дмитрий.

  2. Дмитрий 12.04.2010 в 11:16

    (подписан на сообщения)

    Огромное спасибо Дмитрий за интерес к проблеме.

    1)

    >По поводу тезиса риски должны иметь количественную оценку и надежность должна быть исчисляемой. Я не соглашусь с этим утверждением …

    Если мы говорим, что непрерывность бизнеса зависит от надежности ИТ, то фразы «обеспечив высокую надежность можно заработать (или не потерять) много денег», мало кого устроит. «Сколько вешать в граммах?» На мой взгляд, следует конкретизировать «высокая» и «много».Так, неизвестно что лучше «дутые шесть девяток» или «честные четыре девятки». Именно на это акцент.

    2)

    > Слишком сложная получается модель.

    Большое количество элементов, влияющих друг на друга.

    Конечно, более того при исследованиях оказывается, что имеют место феномены, которые противоречат, на первый взгляд, привычной логике. Поэтому и необходимы сложные расчеты.

    3)

    > Как вводная часть для оценки простых систем …

    Спасибо, действительно именно «вводных» частей в интернете много. Много общих рассуждений, в том числе сравнений HA (High-Availability) и FT (Fault Tolerance) – систем, на сайтах разработчиков обеих архитектур, например, Stratus Technologies и Marathon Technologies

    www.stratustechnology.com...gCritGovtOps.pdf

    www.marathontechnologies.com

    Но все равно, расчетов там нет.

    У меня есть опасения, как бы конкретная тема «как считать, какие модели использовать» не растворилась в «общих рассуждениях» об «высоконадежных» и «отказоустойчивых» комплексах.

    С уважением,

    Аверьянов Дмитрий

    • Константин 14.04.2010 в 14:04

      (подписан на сообщения)

      Существует собственно наука — Теория надежности — ru.wikipedia.org/wiki/%D0...1%81%D1%82%D0%B8 с соответствующим мат аппаратом.

      Надежность ЦОД собственно величина маркетинговая, как и надежность оборудования.

      Бизнес интересует надежность работы бизнес процессов (ну и обеспечивающих их информационных систем).

      С моей точки зрения «козырей мелких, но много» гораздо лучше одного туза.

      То есть если Вам необходимо построить действительно надежную систему, то резервированная (параллельная распределенная) система, расположенная в туалетах, на базе PLAYStantion3, с высокой степенью вероятности выгоднее по стоимости, одной кластеризованной на Супердоме расположенном в ДЦ класса 4 (по устаревшей вдрызг терминологии).

      Для примера посмотрите на построения современных систем — поисковых, википедии, и тому подобное.

      Предвижу возражения — да это не для всех систем, а для тех которые ДЕЙСТВИТЕЛЬНО нуждаются в надежности=>непрерывности.

      Теже банки по собственным планам DRP теряют систему обслуживания банкоматов безболезненно, а почему — критичность низкая — кому нужны деньги будут вынуждены их забрать через оператора.

      То есть надежность любой составляющей — величина исключительно бизнес потребности — как все ИТ вообще.

      Кстати для расчетов сложных схем надежности существует специальный софт, в котором уже введена расчетная и фактическая надежность составных систем вплоть до материнских плат, блоков питания и иных компонентов.

      • Дмитрий Мацкевич 16.04.2010 в 12:21

        Информирую читателей.

        Я сделал запрос одному из западных гуру в области цодостроительства по поводу надежности.

        Он ответил, что данные полученные up time ints. по надежности основаны на статистических данных, причем по tier 4 на основе очень небольшой выборки 6 цодов.

        • Сергей Владимиров 16.04.2010 в 12:38

          Этого следовало ожидать.

          Поэтому эту систему так любят маркетологи и не понимают инженеры.

          Короче говоря, полный бред.

        • Сергей Владимиров 16.04.2010 в 12:43

          Дмитрий,

          Вы вчера очень интересно выступили в конце конференции

          И действительно надо как-то уже объединяться и что-то делать со стандартом на ЦОДы. Н

          Наша компания занимается еще и СКС и может все получиться как со злосчастными стандартами на СКС ГОСТ Р 53246-2008 и ГОСТ Р 53245-2008

          Какая-нибудь компания возьмет и сделает под себя стандарт и в один прекрасный день всем остальными придется все это выгребать

          Я готов оказать посильную помощь, сам отвечаю за проекты по электроснабжению и резервному питанию дата-центров.

  3. Larrikin 16.04.2010 в 13:59

    (подписан на сообщения)

    как все запущено в отрасли :) жаль не знал про круглый стол

    ну давайте в свободной форме пообщаемся на эту тему

    для начала такой вопрос - разделить для методики оценки физики ЦОД и администрирования серверов?

    пример:

    — физики разнесли два сервера в разные концы света в отдельные

    сервачные со своим атомным реактором, а админ тупо ставит обновления на оба сервера сразу автоматом - что будет при очередном глючном обновлении?

    — админы напридумывали системы поэтапного обновления дублирующих серверов с многократными проверками для обеспечения работы хотя бы одного, а оба сервера работают с одного пилота, включенного в тройник с холодильником и микроволновкой

    поэтому считаю, что админы не должны трогать сервер физически — для них это имя dns и доступность по iLo

    для инженеров ДЦ — сервер это черный ящик, который кушает холодный воздух, электричество и связь, а какает горячим воздухом

    ну хорошо, мы согласны считать их раздельно, но как админы договорятся с физиками? как они поймут, что говорят про один и тот же сервер или нет? что будет при перемещении сервера? где тут надежность и предсказуемость?

    а об этом мы поговорим в следующий раз :)

  4. Smirnoff 16.04.2010 в 23:40

    Все ясно, как день, что смешивать ДЦ и ИТ нельзя.

    Вот для примера случаи в атаками

    o 2-3 августа: узлы в сети Gawker Media, в том числе некоторые из наиболее популярных блогов, были отключены от сети на продолжительный период времени в результате атаки DDoS (denial of service attack — атака (системы) с целью нарушения нормального обслуживания пользователей). (Дополнительные сведения см. в газете Нью-Йорк Таймс).

    o 28 июля: провайдер выделенных серверов SoftLayer Technologies и доменный регистратор Dotster, каждый в отдельности, подверглись атакам DDoS, направленным на их сервера доменных имен. Атака на SoftLayer вызвала проблемы с доступностью веб-узлов TechMeme и TwitPic, а тысячи веб-узлов, размещенных в Dotster, были отключены от электропитания.

    o 6-7 апреля: веб-узлы клиентов компании Planet были отключены от электропитания в результате атаки DDoS, направленной на эту огромную хостинговую компанию. “Мы будем обновлять DNS для ослабления рисков атак в дальнейшем, но масштаб атаки был массовым”, написала Planet в своей Twitter-ленте. “Учитывая масштаб атаки, наши сетевые операторы перенаправляли весь трафик сервера имен через наши каналы, защищенные от воздействия DDoS”. Компания Planet размещает свыше 48,000 серверов.

    o 2-5 апреля: доменный регистратор Register.com подвергся атаке DDoS, которая привела к отключению ее клиентов на несколько дней. Компания Register.com является восьмым по величине регистратором, управляющим 2.7 миллионами доменов.

    o 30 марта – 1 апреля: провайдер ”облачных” вычислительных ресурсов компания GoGrid подверглась “большой, распределенной атаке DDoS”, которая прервала обслуживание около половины из ее 1,000 клиентов. “Мы занимаемся хостингом уже больше 8 лет и обычно нам удавалось защитить клиентов от такого сильного воздействия атак как в этом случае”, написала GoGrid в своем блоге.

    o 31 марта: атака DDoS отключила UltraDNS от сети на несколько часов. UltraDNS, которая принадлежит NeuStar, управляет службами DNS высокой готовности электронных продавцов и таких компаний как Oracle и Juniper. Успешные атаки на провайдеров DNS не являются необычным явлением, но эти службы считаются более устойчивыми, чем стандартные провайдеры DNS.

    o 23-24 января: DDoS-атака на серверы DNS больших веб-хостингов и регистраторов корпорации Network Solutions привела к простою или плохой работе сотен тысяч веб-узлов.

    А ЧТО ДЕЛАЮТ наши ЦОДы?

    Просто выключают сервер !!!

    Поэтому сама инфраструктура может и будет отвечать tier super X только, какая от этого польза, если ИТ будет уязвима

  5. Дмитрий Аверьянов 18.04.2010 в 10:00

    (подписан на сообщения)

    Попробуем конкретизировать задачу, чтобы отделять мух от котлет.

    1. Конечно, надежность инфраструктуры ДЦ и надежность ИТ – разные вещи. Будем их рассматривать раздельно, и с точки зрения надежности они имеют последовательное подключение.

    1.1 Надежность инфраструктуры ДЦ. Именно о ней говорится в Uptime Inst. Вообще величину availability в русском языке обычно называю коэффициентом готовности (если не прав поправьте) и вычисляют Кг = MTBF/ (MTBF + MTTR). Правда Uptime Inst. говорит, что это заниженная оценка, так как не учитывает человеческий фактор. Но за неимением других вариантов пока будем отталкиваться от этого определения (или есть другие предложения?).

    1.2 Надежность ИТ будем оценивать тем же Кг.

    1.3 Как следствие п.1: имея максимальный уровень TIER IV (99,995) и ИТ с семью девятками, то никогда не получим в целом даже пяти девяток. Uptime Inst. это поясняет том, что мгновенное отключение питания в любом случае отключает сервисы на 4 часа (по статистике Uptime Inst) и говорить о простое 5 мин. в год, следовательно, не приходится.

    2. Будем считать, что определяется только внутренними факторами системы. Для оценки внешних воздействующих факторов обычно употребляется термин «живучесть». Поэтому природные катаклизмы, хакерские атаки и т.п. в расчете надежности учитывать не будем.

    3. Несколько повторюсь для Константина: при расчетах – справа требования (пять девяток), слева формулы (по Вашей ссылке), в середине масса других промежуточных действий, которые никем не регламентированы. Если трем людям дать рассчитать один проект, то получим четыре разных результата в оценке надежности. Вначале каждый задастся разными критериями отказа и нарисует свою последовательно-параллельную схему. Но даже если им выдать одну и ту же схему, то все примут разные допущения и возьмут разные модели. В итоге получат или разные оценки или заданный в ТЗ ответ. Теория надежности слишком общий инструмент для расчета сложных специфических систем. Для каждой предметной области требуются прикладные трактовки. Это относится и к оценкам надежности.

    4. Дополнительные вопросы в студию:

    4.1 Может ли кто поделиться расчетами надежности резервируемых систем применительно к ДЦ или ИТ?

    4.2 Uptime Inst говорит, что: Надежность ДЦ зависит от успешной и интегрированной работы по крайней мере 16 отдельных инфраструктурных подсистем (Tier Classifications Define Site Infrastructure Performance). Каков перечень этих минимум 16 подсистем?

    • Семеныч 19.04.2010 в 09:30

      Хотелось бы получить статистические данные по поводу мгновенного отключения электропитания. И о каких сервисах идет речь?

      Имеется в виду операторы связи?

      • Дмитрий Аверьянов 21.04.2010 в 22:12

        (подписан на сообщения)

        The time for IT to recover from a type outage such as momentary power loss is four hours at sites of any Tier.

        Время восстановления IT сервисов после отключения электричества, например, при мгновенной потери мощности, составляет четыре часа на сайта любого уровня (TIER).

        Взято оттуда же: «Tier Classifications Define Site Infrastructure Performance»

  6. Константин 19.04.2010 в 09:35

    (подписан на сообщения)

    Любимый мозоль :-) , Дмитрий, отвечу.

    Немного теории.

    Предлагаю отмести в сторону «мух и котлеты».

    Раз тема заинтересовала.

    Мне неизвестен-непонятен термин доступность «avalability» в терминах надежности центров обработки данных, отнеся его к коммерчески маркетинговым выкидываем из рассмотрения(см. ниже), строго говоря - туда же «живучесть», которая обычно рассчитывается для техники специального применения.

    Полный(необходимый и достаточный) перечень терминов надежности приведен в

    НАДЕЖНОСТЬ В ТЕХНИКЕ ОСНОВНЫЕ ПОНЯТИЯ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ ГОСТ 27.002-89

    к примеру - sklad-zakonov.narod.ru/gost/G27002-89.htm

    Основные

    1.1. Надежность - Reliability, dependability

    Свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, хранения и транспортирования.

    Примечание. Надежность является комплексным свойством, которое в зависимости от назначения объекта и условий его применения может включать безотказность, долговечность, ремонтопригодность и сохраняемость или определенные сочетания этих свойств

    1.2. Безотказность - Reliability, failure-free operation

    Свойство объекта непрерывно сохранять работоспособное состояние в течение некоторого времени или наработки

    1.3. Долговечность - Durability, longevity

    Свойство объекта сохранять работоспособное состояние до наступления предельного состояния при установленной системе технического обслуживания и ремонта

    1.4. Ремонтопригодность - Maintainability

    Свойство объекта, заключающееся в приспособленности к поддержанию и восстановлению работоспособного состояния путем технического обслуживания и ремонта

    1.5. Сохраняемость - Storability

    Свойство объекта сохранять в заданных пределах значения параметров, характеризующих способности объекта выполнять требуемые функции, в течение и после хранения и (или) транспортирования

    Напоминаю, что первое возникновение ГОСТ по надежности относиться к временам, когда стандарты ISO были переводами с ГОСТ (что, кстати, подтверждается наличием англоязычной терминологии в стандартах), а не наоборот.

    ...

    КОМПЛЕКСНЫЕ ПОКАЗАТЕЛИ НАДЕЖНОСТИ

    6.26. Коэффициент готовности - (Instantaneous) availability function

    Вероятность того, что объект окажется в работоспособном состоянии в произвольный момент времени, кроме планируемых периодов, в течение которых применение объекта по назначению не предусматривается

    6.27. Коэффициент оперативной готовности - Operational availability function

    Вероятность того, что объект окажется в работоспособном состоянии в произвольный момент времени, кроме планируемых периодов, в течение которых применение объекта по назначению не предусматривается, и, начиная с этого момента, будет работать безотказно в течение заданного интервала времени

    6.28. Коэффициент технического использования - Steady state availability factor

    Отношение математического ожидания суммарного времени пребывания объекта в работоспособном состоянии за некоторый период эксплуатации к математическому ожиданию суммарного времени пребывания объекта в работоспособном состоянии и простоев, обусловленных техническим обслуживанием и ремонтом за тот же период

    ...

    ---------------------------------------------------------

    Следует иметь в виду что ЦОД система работающая непрерывно, поэтому так часть параметров для нее не имеет смысла. Строго говоря для ЦОД я бы оперировал единственным параметром - Надежность.

    Поясню - дело в том что все аварийные с точки зрения техники и эксплуатации, режимы, для ЦОД таер 4 являются, внимание, ШТАТНЫМ режимом работы. Именно поэтому раздел 6 - комплексные показатели - смысла не имеют, они работаю только для отдельных подсистем.

    ЦОД проектируется на работу с уровнем отказов:

    — электроснабжений,

    — систем бесперебойного электропитания,

    — системы вентиляции и кондиционирования, и так далее.

    Причем для поддержания высокого уровня надежности, каджая резервированная система проектируется с запасом, что бы выведение части системы на плановое техническое обслуживание (ремонт).

    см. 7. РЕЗЕРВИРОВАНИЕ

    7.1. Резервирование — Redundancy

    Способ обеспечения надежности объекта за счет использования дополнительных средств и (или) возможностей, избыточных по отношению к минимально необходимым для выполнения требуемых функции

    см. так же

    7.17. Резервирование с восстановлением — Redundancy with restoration

    Резервирование, при котором восстановление отказавших основных и (или) резервных элементов технически возможно без нарушения работоспособности объекта в целом и предусмотрено эксплуатационной документацией

    ---------------------------------------------------------

    Относительно расчетов.

    не делалось к сожалению, долго, дорого, никому не нужно. Маркетинг и так напишет сколько надо :-) .

    Так как расчет надежности — одна из инженерных задач — и выполняется по запросу/в интересах некоторого Заказчика, то самое главное что бы Заказчика УДОВЛЕТВОРИЛА схема системы и коэффициенты надежности составляющих ее элементов. Далее просто математика — или перепроектирование систем(комплекса систем) надежность которых неудовлетворительно повлияла на выходной показатель Надежности.

    ГОСТ 27.301-95 Надежность в технике. Расчет надежности. Основные положения

    sklad-zakonov.narod.ru/gost/G27301-95.htm

    Такова теория.

    Конечно разговаривать нужно с элементной схемой для расчета надежности.

    А перечень подсистем, да был бы интересен.

  7. Larrikin 19.04.2010 в 19:21

    (подписан на сообщения)

    Очень можеть быть, что сама по себе надежность в наших условиях НЕ НУЖНА

    Для практики полезно и важно уметь ПРОГНОЗИРОВАТЬ ПОСЛЕДСТВИЯ различных ситуаций

    Пример — идет тендерный комитет, обсуждают закупку AP7723 (Rack-mount Transfer Switches)

    в первом случае представитель IT заявляет, что закупка этих устройств, согласно расчетам, повысит надежность, допустим с 87% до 88%

    скорее он увидет пустоту в глазах бизнеса и утомленный вопрос типа «а без них работать будет?» Ну будет, конечно, но может не всегда.

    второй вариант на том же тендерном комитете айтишник рассказывает, что унаследованные сервера имеют по 1 блоку питанию, замена стоит столько, а покупка десятка Rack-mount Transfer Switches столько. Если их не купить, то при пропадании питания на таком-то шкафу упадут такие-то сервисы, причем аварийно и хз не сгорят ли вообще

    Бизнес воодушевленно согласовывает закупку да еще торопит, а то вон весной помните че было.

    Ну хорошо, а как прогнозировать последствия разных планируемых и аварийных событий? Об этом поговорим в следующий раз :)

    • Семеныч 19.04.2010 в 20:19

      Браво Larrikin!!!!

      Очень грамотно засветил вопрос.

      Действительно нам нужно уметь ПОПУЛЯРНО на пальцев уметь объяснять руководству, что будет, если ...

      Вот как популярно объяснить зачем нужно Х 9-ток вряд ли удасться.

      Вернее только можно действительно вот так, нам нужна эта штука для того, чтобы Вы могли зарабатывать бабки...

      • Константин 20.04.2010 в 08:01

        (подписан на сообщения)

        AP7723 Rack-mount Transfer Switches

        Хороший пример. Так обычно все и происходит.

        Забыв произвести расчеты принимают решение на интуитивном уровне, а зачем? и так же все понятно! 2 лучше чем 1, правда?

        Что самое интересно что надежность (именно надежность системы при этом падает) попробуйте рассчитать сами — www.docstoc.com/docs/4211...ty-Block-Diagram

        Трансфер свич в данном случае устройство Voter — снижающий общую Надежность системы.

        Что бы не возникало мыслей о том что за дурацкая наука которая противоречит очевидным вещам, предлагаю задуматься и понять почему введение в цепочку еще одного элемента снижает общую и надежность системы и время наработки на отказ...

        А для расчета подобных вещей составляются Деревья отказов (деревья отказов объекта, представляющие графическое отображение причинно-следственных связей, обуславливающих определенные виды его отказов (стандарт МЭК 1025)).

        Структура центра обработки данных:

        • Константин 21.04.2010 в 11:31

          (подписан на сообщения)

          Предлагаемая к рассмотрению схема включает 14 выделенных систем инженерии и связи ЦОД 4-го уровня.

          Соответственно двухкратное дублирование всех систем.

          Вплоть до разнесения резерва в независимые помещения.

          Территория размещения здания ЦОД, само здание, приведены для полноты картины или если кому то понадобится академически точный расчет.

          Перекрытие обозначений систем на схеме, предполагает наличие зависимости систем друг от друга.

          Отдельные оговорки по части систем:

          — ИБП 2*2N

          — кондиционирование 2N

          — автоматика N

          N равно 1-му модулю объекту элементу.

          • Larrikin 21.04.2010 в 15:10

            (подписан на сообщения)

            а где схема-то? чего рассматривать?

            • Дмитрий Мацкевич 22.04.2010 в 15:46

              Картинку Константин прислал.

              Скоро разместим картинку

              Чуток терпения

              Проблема в Новосибиске с доступом в инет — вчера не смог войти и дать администратор не знала куда картинку в какой коммент поместить.

          • Семеныч 29.04.2010 в 09:31

            Константин,

            Ох не нравится мне эта схема.

            Если уж мы делаем ИБП 2*2N

            То надо дублировать и систему кондиционирования, а иначе она узким местом будет в Вашей системе

            Да и автоматика N это не есть хорошо.

            Ведь

            1) датчики могут выйти из строя

            2) сработать неправильно

          • Дмитрий Аверьянов 29.04.2010 в 23:40

            (подписан на сообщения)

            < Предлагаемая к рассмотрению схема включает 14 выделенных систем

            Может начать с какой-нибудь одной подсистемы? Например, электропитания, Можно посчитать так: 2*N, т.е как дублированная группа, где каждый N имеет MTBF мильон часов, и, следовательно, в резерве они НИКОГДА не откажут. А можно детально рассмотреть эту подсистему, определить единые точки отказа, например, АВР.

            Также хотелось бы «запихнуть» в формулу такие вещи как: «короткое замыкание», которое уничтожило датацентр компании «Hosting.ua» (ссылку см. ниже) или другой случай:

            однажды на узле связи пропало внешние питание. Завили ДГУ, прогрели, подали нагрузку. Но ДГУ под нагрузкой выдал существенно больше 220В. Результат — сгоревшая аппаратура – незащищенная ИБП, а также ИБП, «защитившие» аппаратуру. В первом («Hosting.ua») и втором случае, речь уже идет не об отказах и вынужденных простоях, а о разрушении систем.

  8. Дмитрий 20.04.2010 в 13:22

    (подписан на сообщения)

    Константин, по поводу терминологии:

    1) конечно вначале нужно договориться о терминах

    2) святая вера в наши ГОСТы – не лучший путь. Качественная их разработка была прекращена еще до их отмены (2003 г. – регламенты). А время идет…

    3) что бы не ломать копья, как вариант предлагаю считать availability (Uptime Inst.) = стационарный коэффициент готовности. Более подробно см. «Готовность и доступность – почувствуй разницу» Вестник связи 2005 №8.

    Larrikin,

    < Бизнес воодушевленно согласовывает закупку да еще торопит, а то вон весной помните че было.

    Жизнь обычно учит людей думать: одни будут считать вначале правильно надежность, что бы не считать потом убытки, а другие наоборот. Видимо это понимание придет современен.

    • Larrikin 20.04.2010 в 16:49

      (подписан на сообщения)

      и какие у вас получились три последние правильно рассчитанные надежности, если не секрет?

      • Дмитрий Аверьянов 21.04.2010 в 22:18

        (подписан на сообщения)

        К сожалению или к счастью, но пока мы тоже считаем надежность по принципу «сколько в ТЗ задано, столько и в ответе». А заказчик смотрит в интернет видит «кучу девяток» и сует их нам в ТЗ, называя по «аналогии с другими системами».

  9. Дмитрий Аверьянов 21.04.2010 в 22:24

    (подписан на сообщения)

    1. Ранее я просил уточнить 16 систем, которые Uptime Inst. считает ключевыми для надежности ЦОД, у Вас 14. Интересно, все таки, что за системы и как они соотносятся с теми 16?

    2. Хотелось по-подробней про системы и способы резервирования, особенно важно учесть единую точку отказа. Как правило она всегда присутствует даже в задублированных системах.

    • Константин 22.04.2010 в 08:25

      (подписан на сообщения)

      Картинка кстати так и не видна.

      Про количество систем. Я никогда не видел этого самого перечня, ни «у них» ни у нас. И решил все таки его создать, с помощью участников обсуждения.

      По рассмотрении схемы могу добавить еще пару систем

      15. Насосная станция.

      16. Сетевое оборудование WAN&LAN.

      Картинку выложил —

      picasaweb.google.ru/kbelk...2810411396208690

      тут.

  10. Larrikin 22.04.2010 в 19:28

    (подписан на сообщения)

    осуждаю отсутствие своей вики на сайте

    • Дмитрий Мацкевич 30.04.2010 в 22:44

      Спасибо Вам за хорошую идею.

      На заметку поставил, осталось найти время все настроить и прикрутить

  11. Дмитрий Аверьянов 28.04.2010 в 20:59

    (подписан на сообщения)

    К вопросу о надежности: frichx.livejournal.com/2487.html

    "В Одессе горел датацентр компании «Hosting.ua» А там, навярняка, кластеры и СХД с 0,99999 были. Только не 5 минут простоя оказались, а неделя.

  12. Larrikin 29.04.2010 в 09:58

    (подписан на сообщения)

    Вариант, как можно формализовать хотелки и мечталки о надежности дата-центра:

    — создание отраслевого стандарта на моделирование дата-центра. Не в смысле рисования в автокаде 3д, а смысле отображения активного и пассивного хозяйства в удобную для рассчетов базу с легкими, быстрыми и методами создания и поддержания актуальности с некоторой избыточностью для контроля внутренней целостности. Наработки есть.

    — Разработка методов планирования на модели требуемых изменений. Не думаю, что открою тайну в том, что в наполнении ЦОДа постоянно требуются изменения типа добавления/удаления/перемещения/коммутации

    — Разработка методов автоматического расчета надежности для текущей и любой планирумой конфигурации. Например, для каждой закупки патч-кордов со временем все лучше уточняется надежность этой партии. Так как патчи пронумерованы, это вполне полезно.

    — Разработка методов принятия решений по типовым задачам. Реагирование на особые режимы работы, задача на установку нового, перемещение и т.п.

    — Разработка мерялок. Так как модель у всех будет стандартная, то для оценки надежности в любой момент можно получать некоторые условные коэффициенты по разным признакам. Тогда не раскрывая внутренней кухни можно будет хвастаться не маркетинговыми, а реально проверяемыми цифрами.

    Всё еще осуждаю отсутствие вики на сайте.

    • Дмитрий Мацкевич 30.04.2010 в 23:04

      LAR> создание отраслевого стандарта на моделирование дата-центра. Не в смысле рисования в автокаде 3д, а смысле отображения активного и пассивного хозяйства в удобную для рассчетов базу с легкими, быстрыми и методами создания и поддержания актуальности с некоторой избыточностью для контроля внутренней целостности. Наработки есть.

      Идея очень интересная.

      Надо бы ее обсудить подробнее

      В принципе ресурсу на эту задачу выделить можно

      То же есть интересные наработки + опыт программирования, можно действительно сделать полезный инструмент.

      LAR> — Разработка методов планирования на модели требуемых изменений. Не думаю, что открою тайну в том, что в наполнении ЦОДа постоянно требуются изменения типа добавления/удаления/перемещения/коммутации

      Надо бы раскрыть по конкретнее на примере, чтобы была понятна актуальность этой задачи

      LAR> — Разработка методов автоматического расчета надежности для текущей и любой планирумой конфигурации. Например, для каждой закупки патч-кордов со временем все лучше уточняется надежность этой партии. Так как патчи пронумерованы, это вполне полезно.

      Думаю, что эта задача автоматического расчета надежности очень сложная задача, так как у нас практически нет данных по надежности отдельных элементов, то расчитать надежность системы в целом без этого невозможно.

      То есть производители не дают данные на наработку на отказ и что мы сможем посчитать?

      Вывести статистически не получится

      1) Выборка маленькая для сложных элементов

      2) Условия разнеы для разных ЦОДов, например, те же параметры электроснабжения

      3) Кстати, патч-корды — одно дело изготовляемые заводским способом, а если вручную доморощенным способом?

      LAR>— Разработка методов принятия решений по типовым задачам. Реагирование на особые режимы работы, задача на установку нового, перемещение и т.п.

      Можно решить задачу, используя подходы с описанием правил действия экспертом в тех или иных случаях

      LAR>— Разработка мерялок. Так как модель у всех будет стандартная, то для оценки надежности в любой момент можно получать некоторые условные коэффициенты по разным признакам. Тогда не раскрывая внутренней кухни можно будет хвастаться не маркетинговыми, а реально проверяемыми цифрами.

      Мысль очень интересная !!!

      Однако при реализации столкнемся с массой скрытых нюансов.

      LAR>Всё еще осуждаю отсутствие вики на сайте.

      Вас услышал...

      • Larrikin 30.04.2010 в 23:54

        (подписан на сообщения)

        ответил через форму сайта

      • Константин 04.05.2010 в 14:04

        (подписан на сообщения)

        создание отраслевого стандарта на моделирование дата-центра, да интересно — как научная работа, но ...

        Вопросы:

        Цель создания стандарта? (самопиар создателей не в счет).

        Коммерциализация и способы поддержания?

        Под чьей эгидой планируется создать стандарт?

        • Larrikin 04.05.2010 в 20:22

          (подписан на сообщения)

          Константин, вы просто так спрашиваете или таки имеете что-то предложить?

          Формы коммерциализации придуманы, эгида важна ли?

          Есть ресурсы поучаствовать? пишите larrikin@newmail.ru

          • Константин 04.05.2010 в 21:59

            (подписан на сообщения)

            Анонимность это хорошо,

            вселяет некие ложные чувства...

            Правда?,

            Сергей Галкин, 1976 г.р. из Воскрсенска, моб.тел +7 905 5152783. Ну и так далее... информации много, нокак то серьезность намерений не прослеживается.

            Но можно ответы в студию?

            Ресурсы есть, при серьезности намерений — ресурсы компании системного интергатора.

            PS Мои извинения Дмитрий.

          • Larrikin 13.05.2010 в 15:26

            (подписан на сообщения)

            системная интреграция слишком анонимно, в-основном нужны ресурсы программировать

    • Дмитрий Аверьянов 04.05.2010 в 22:36

      (подписан на сообщения)

      Замахнуться на отраслевой стандарт – сильное предложение, но когда-нибудь к этому придут. В любом случае, вначале придется ответить на ряд простых вопросов, например,

      А) неужели для FT-ЦОДа (TIER IV) достаточно резервирования по схеме 2 (N+1), но не важно какой надежностью обладают сами резервные элементы? Например, MTBF = 500 часов, а время восстановления месяц?

      Б) хорошо: 2 (N+1), только в реальных системах все равно будут единые точки отказа. Но в одних это будет одна точка, а в другой их 10. Но формально ставим все равно между ними знак «=».

      < — Разработка методов автоматического расчета надежности для текущей и любой планирумой конфигурации. Например, для каждой закупки патч-кордов со временем все лучше уточняется

      Важно понимать, что надежность резервируемой системы может завесить не столько от надежности самих элементов, сколько от качества такого резервирования. «Кучу девяток» можно получить только на основе резервирования и именно ее реализацией будет определяться надежность конечной системы. В принципе можно из абсолютно ненадежных элементов построить высоконадежную систему.

      Про патч-корды: одним из методов оценки надежности, помимо моделирования, может быть экспертиза. Комиссия определяет уровень надежности отдельных компонентов, фиксирует минимальной уровень надежноститех же патч-кордов, для одного класса (производитель, марка, партия и т.п.) будет один коэффициент, например, замечен самопальный – минимальный коэффициент и т.п.

      Ну а подтверждение самых «высоких намерений» проведение натурных испытаний на объекте:

      Комиссия «перерубает» силовой кабель (лучше конечно КЗ) и контролирует:

      А) все ли подсистемы переключились на резервный (не было ли остановки сервисов)

      Б) за сколько времени был восстановлен основной ввод (уложились ли в норматив)

      Делов то!

      < — Разработка мерялок. Так как модель у всех будет стандартная

      К вопросу об измерениях. Постоянно слышим «высокая производительность и высокая надежность». Мерить первый параметр научились давно: масса тестов железа и софта. А вот второй мерить до сих пор не могут.

      Реально у эксплуататоров в одной руке рекламные проспекты с «кучей девяток» что на ИТ- оборудование, что на инфраструктуры – а в другой – реальная статистика отказов на объекте. И почему-то они друг с другом не стыкуются.

      Поэтому со временем кроме загрузки процессора и оборотов вентилятора в системы мониторинга будут включать и другие мерялки.

      • Larrikin 05.05.2010 в 13:43

        (подписан на сообщения)

        > А) неужели для FT-ЦОДа (TIER IV) достаточно резервирования по схеме 2 (N+1), но не важно какой надежностью обладают сами резервные элементы?

        Это важно для повышения объема продаж инженерного оборудования. Вы правда думаете, что производителя ИБП волнует число обесточенных серверов в какой-то серверной где-то в России?

  13. Петр Луцикович 14.06.2010 в 10:13

    Да, проблема надежности инженерной инфраструктуры это одно, а реалии Российские это другое.

    17 марта в ЦОДе Golden Telecom были опечатаны все сервера из-за того, что на ifolder кто-то выложил детскую порнографию.

    Пришли и опечатали.

    Пострадали пользователи.

    При этом Golden Telecom предлагал сотруднчество.

    Вот она реалия — явный заказ выполнили кого-то

    То есть очень просто остановить работу — выложи порнографию, а затем настучи в спецслужбу... Вот она и надежность работы