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

Дмитрий Мацкевич опубликовал 10 апреля 2010 | | Ваш вопрос или сообщение
Оценка новости или статьи: Больше единицы поставить не могу :-(((

(проголосовало 5, ждем и Вашу оценку)

Загрузка ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы:

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

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

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

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

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

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

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

Ваше сообщение (вопрос, ответ, комментарий)

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

Дмитрий, добрый вечер,
Спасибо за Ваши интересные вопросы
К сожалению, я пока не встречал ни в литературе, ни в интернет методики оценки надежности ЦОД или хотя бы оценки надежности работы одной системы.
По поводу тезиса риски должны иметь количественную оценку и надежность должна быть исчесляемой.
Я не соглашусь с этим утверждением по одной просто причине.
Слишком сложная получается модель.
Большое количество элементов, влиящих друг на друга.
Также существуют различные внешние возмущающие воздействия на систему, которые по идее тоже надо оценивать — одно дело например электрическая система в городе Х, другое в городе Y, человеческий фактор, который вообще не поддается оценке, ну и действия различных органов.
Получается, что можно только основываться на статистических данных и делать какие-то реперные точки, что и сделал UpTime Institute
Но он это сделал на оснвое полученных данных от американских дата-центров.
Если появится инфомация у меня, то обязательно напишу
С Ув.Дмитрий.

Инженерная инфраструктура центров обработки данных (ЦОД)

Проектирование и строительство центра обработки данных (ЦОД, дата центр), построение и использование облачных вычислений и SaaS сервисов

СЕМИНАР ИНЖЕНЕРНАЯ ИНФРАСТРУКТУРА ЦОД

Рубрики

Полезные ссылки