Нужна статистика по крупному ДЦ

[Прохожий]

Привет /all!

 

Мне для кое-каких моих личных нужд и проработок идей неблизких горизонтов нужна практическая статистика по эксплуатации крупных ДЦ (100++ стоек). Речь идет о некотором количестве статистических показателей, связанных с надежностью, наработкой на отказ, временем и способами восстановления размещаемой в ДЦ техники. Просьба в гугель меня не посылать, я только оттуда. Там все больше аналитика по рынку и баблу, а мне статистика и анализ нужны в технологических плоскостях.

 

За ответы на интересующие меня вопросы я готов заплатить разумные деньги. Поскольку понятие "разумные" глубоко индивидуально, то оставим этот вопрос для прямой дискуссии с теми, кто нужной мне информацией обладает, либо может перелопатить в нужный мне вид имеющуюся у него инфу. Интересуют только практики, теоретикам и аналитегам - просьба не беспокоиться.

 

Соответственно, вся эта информация дальше меня не уйдет, ибо только лично мне и нужна. Гарантирую а) анонимность источника б) дальнейшее нераспространение в) отсутствие любого прямого либо косвенного ущерба для работодателя.

 

Как-то так. Если кто-то знает такого рода людей и меня с ними познакомит - буду крайне признателен.

 

Заранее благодарен!

[wanderer_from]

есть тут у меня один знакомый аналитик... ;) ну, он тебе щас в личку постучится...

[zoro]

Дмитрий Мацкевич, занимался/занимается этими вещами... в принципе на коленках может посчитать... а вот детальную статистику.. если в гугле его не найдете :) могу свести...

[Прохожий]

zoro, буду признателен!

[pers123]

Привет /all!

 

Мне для кое-каких моих личных нужд и проработок идей неблизких горизонтов нужна практическая статистика по эксплуатации крупных ДЦ (100++ стоек). Речь идет о некотором количестве статистических показателей, связанных с надежностью, наработкой на отказ, временем и способами восстановления размещаемой в ДЦ техники. Просьба в гугель меня не посылать, я только оттуда. Там все больше аналитика по рынку и баблу, а мне статистика и анализ нужны в технологических плоскостях.

 

За ответы на интересующие меня вопросы я готов заплатить разумные деньги. Поскольку понятие "разумные" глубоко индивидуально, то оставим этот вопрос для прямой дискуссии с теми, кто нужной мне информацией обладает, либо может перелопатить в нужный мне вид имеющуюся у него инфу. Интересуют только практики, теоретикам и аналитегам - просьба не беспокоиться.

 

Соответственно, вся эта информация дальше меня не уйдет, ибо только лично мне и нужна. Гарантирую а) анонимность источника б) дальнейшее нераспространение в) отсутствие любого прямого либо косвенного ущерба для работодателя.

 

Как-то так. Если кто-то знает такого рода людей и меня с ними познакомит - буду крайне признателен.

 

Заранее благодарен!

В принципе есть в мире место http://uptimeinstitute.com/

У них достаточно обширная статистика и глубокая экспертиза,

в частности принятые классификации по надежности ДЦ разработаны ими.

И в стране есть некоторое количество экспертов партнеров uptime...

Также есть контакты людей занимающихся Bussiness continuity и сертифицированных институтом BCI.

http://www.thebci.org/

Если интересны такие контакты, пишите в почту.

Edited April 10, 2013 by pers123

[Прохожий]

Если интересны такие контакты, пишите в почту.

Спасибо, К.О.! )))))

 

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

 

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

[pers123]

Если интересны такие контакты, пишите в почту.

Спасибо, К.О.! )))))

 

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

 

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

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

[Прохожий]

 

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

В смысле "очень систематизированная"?

[karpa13a]

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

имея небольшой опыт аренды стоек в разных ДЦ, полагаю не сильно промахнусь.

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

отказов матерей и процов не было.

 

в первые три месяца вылетают БП и память.

память стендовыми нагрузками не определяется. выявляются в основном под реальной нагрузкой.

 

один раз из купленных ССД интел 16 штук, один не взлетел из коробки. (брали на пробу. результатом довольны, посмотрим сколько будут ездить под нашими нагрузками)

 

потом(через 2-3 года) летят в основном диски. сегейты, хитачи разницы особой нет (брэндированые).

 

сервера HP и Dell, закупаем сейчас Dell, тупо фичастей и дешевле (ip kvm на борту) при тех же самых показателях. или больше памяти и бодрее процы за теже деньги.

 

из рутеров один раз после sh ver вылетела 7204VXR G1 меняли по гарантии)

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

циска неподъемная на 10G.

 

по замене - если до ДЦ далеко (>600км)- то курьеры (или доставка) от поставщиков сами с обслуживающим персоналом ДЦ разбираются (никогда не было проблем).

если в пределах "шаговой" доступности - то можно и скататься) с технарями же нужно поддерживать контакты)

[Прохожий]

karpa13a, спасибо за сводную картину.

 

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

[pers123]

 

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

В смысле "очень систематизированная"?

 

У таких людей устоявшаяся терминология, типа RTO/RPO/MTO и они в этих терминах работают.

[Прохожий]

 

У таких людей устоявшаяся терминология, типа RTO/RPO/MTO и они в этих терминах работают.

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

[karpa13a]

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

хмхм

ну сам же понимаешь, что фирмовая сан-овская стойка или там ибм отличается от набивки какмнить депо с длинковским коммутатором)

 

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

т.е. минимум 2 подхода на инцидент. хотя в зависимости от отвественности арендатора - если нормально инвентаризовано железо - то один подход.

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

 

в случае же непоняток - ипе квм по запросу или личный заезд с тасканием серверов в аквариумы и обратно по необходимости)

 

в одном дц например пачкорды и шнуры питания оне делают только сами.

в другом же - коммунизм - приходите - вот ваша стойка - чо хотите то и делайте)

 

так что в среднем по больнице - да 36.6 один инцидент в год на юнит)

Edited April 10, 2013 by karpa13a

[Skylaer]

Меньше на юнит в год. Где-то 0,2-0,25 на юнит.

Это включая как траблы железа, так и ДЦ.

 

Правда есть уникальные ДЦ, где вот уже 2 года вообще нет проблем.

[AlexBT]

Прохожий, а что, уже расчетных нормативов на ЗиП совсем не осталось?

В конечном итоге, все сводится к строчке в контракте - количество ЗиП по договору в процентах от поставляемого.

А срок службы компьютерной техники - в пределах сроках амортизации, выбираемой бухгалтерией предприятия ;-)

[Sonne]

Могу рассказать как после пожара на Щепкина 51 в Москве натирал спиртом интерфейсные платы 7200 цисок. 80 процентов удалось спасти и немедленно запустить сервисы, потом примерно за 6 месяцев восстановленное плавно выходило из строя, но было время это исправить. Потом я учился у старших товращией строить узлы с резервированием, узнал о пользе связки OSPF+BGP. Полученный опыт позже реализовал уже сам в проекте. Успел можно сказать аккурат к блэкату на М9. Во время блэкаута сидел в консоле на бордере на М9 и смотрел как один за одним умирают пиры MSK-IX. Примерно после 80% ухдящих погасли и мы, но второй узел полностью взял на себя всю нагрузку - резервированные независимые аплинки, независимые опорная сеть, географические разнесенные объекты сделали свою работу. В те времена не все крупные интернет провайдеры могли похвастаться таким.

 

Все это конечно не про ДЦ, но зерно общее есть. Точно так же как у Совинтела когда они внедряли MEN от Нортела временами от MAC шторма падала разом вся сеть (и никакой резервный канал от совинтела же не помогал), так же и крутой дисковый рейд массив набитый новейшими дисками одной партии может разом накрыться из-за общего деффекта партии. При прочих равных всегда лучше иметь два сервера похуже разнесенных в разных локейшины чем один супер-пупер лучший в лучшем датацентре.

 

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

 

Я считаю что самая сильная ( нельзя говрить лучшая) школа это переживание реального опыта катастрофических отказов. Конечно этот опыт лучше ляжет на подготовленный ум вооруженный теорией вероятностей из хорошего института.

[karpa13a]

новейшими дисками одной партии может разом накрыться из-за общего деффекта партии

и самое печальное, что ценой железа от потери данных хрен защитишься.

 

так что надежная система на не надежных реле. или как там в оригинале)

[st_re]

 

так что в среднем по больнице - да 36.6 один инцидент в год на юнит)

 

Как то очень плохое железо должно быть. Или очень пыльно-жарко итд в ДЦ. Так, на взгляд, 1 на 4-5 устройств (не юнитов, есть и 1 и 2 и 4 юнита) в год в среднем, больше похоже на правду. Если за пару месяцев не вымерло, то первые 5 лет кроме дисков и не бывает ничего почти. Сейчас часто железо снимаем, по факту "мало стало", 2005-2006 года установки, но рабочего, с таким же аптаймом. В массе своей железо брендовое, хотя есть разной степени брендовости :) . Но это "в среднем", естественно. была вон серия, 5 из 5, через 1.5 года все поимели траблы с дисками. Были серии с плохим биосом, тупо бутится раз в несколько месяцев. После перепрошивки не бутится. Были неудачные крепления шнурков к контроллерам, от вибрации кулеров через год начинали валиться ошибки на чтение-запись. (это отнюдь не самосбор). Но это скорее исключение.

[karpa13a]

Но это скорее исключение.

да - про юнит я чтото не то уже на ночь ляпнул.

инцидент на устройство в год.

опять теже апгрэйды.

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

еще и проблемы всплыли непонятные с циской - через 5 минут перестают пакетики бегать. пока cle arp не сделаешь на ипе.

пока недопёрли что проблема не в железе а в голове - парни таскале серваки туда-сюда.

так весь годовой план по своему оборудованию и перевыполнили)

[Прохожий]

Прохожий, а что, уже расчетных нормативов на ЗиП совсем не осталось?

В конечном итоге, все сводится к строчке в контракте - количество ЗиП по договору в процентах от поставляемого.

А срок службы компьютерной техники - в пределах сроках амортизации, выбираемой бухгалтерией предприятия ;-)

За что я тебя люблю, так это за то, что ты любой вопрос легко приводишь к строительству, ГОСТ, СНиП и нормам вещевого довольствия в мирное и военное время. )))) Но здесь вопрос с моей текущей деятельностью не связан вообще, равно как и с контрактами, бухгалтерией и т.д. Это вообще-то некие раздумья про очень отдаленное будущее.

 

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

Смотри, есть разные уровни. Если в качестве области рассматривать отдельно взятый ДЦ, то предметом анализа, в том числе вероятностного, являются события в нем, вокруг него, и происходящие из этих событий сценарии развития. При этом, замечу, что на каждому уровне сценарии развиваются со сложными, но вполне конечными связями между этими уровнями. Ну, то есть понятно, что если коротнул БП, то выбьет всю группу, а если пожар - то вероятно остановится вся секция между п/п стенами, а если навернулось питание - то встанет все запитанное железо.

 

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

 

так что в среднем по больнице - да 36.6 один инцидент в год на юнит)

Меньше на юнит в год. Где-то 0,2-0,25 на юнит.

Это включая как траблы железа, так и ДЦ.

инцидент на устройство в год.

опять теже апгрэйды.

Предлагаю следующую модель, представьте себе, что Вам предложены следующие условия:

1. Ваше железо стоит где-то даже хер знает где, ему дают "пять девяток" по питанию, отводу тепла и коннективити. Среда соответствует всем требованиям по температуре, влажности, пыли и т.д.

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

3. Любой интерфейс управления на любой железяке (KVM, serial, USB, Eth) на 100% доступен Вам удаленно, в том числе вкл/выкл по питанию любой индивидуальной железки.

4. Любая четко поставленная задача вида "Железяку ID JR458-15 обесточить, вскрыть, идентифицировать модуль DRAM №2, заменить на модуль p/n 159876 из состава ЗИП, закрыть, поставить под ток, вынутый модуль - в сток неисправных" выполняется в строгом соответствии с заданием в течение 30 минут.

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

 

При таком наборе условий каков был бы профиль работы в терминах удельного числа п. 4 и п. 5 на единицу оборудования или юнит? С учетом того факта, что число по п.3 может быть любым, и на экономику процесса вообще не влияет.

 

Забыл существенное:

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

1b. С точки зрения стоимости среднего юнита в год оно встанет Вам дешевле любого сегодняшнего предложения раза в два.

1в. Меньше 48U не отгружается ;)

 

Только не надо спрашивать меня "почему нельзя зайти в рабочую зону?" Давайте поиграем в модельки, вот таковы заданные условия игры.

 

P.S. Нет, я не собираюсь делать ДЦ в военном бункере или на закрытой территории за колючей проволокой. Хотя мысль забавная :)

[visir]

ИМХО в твоей модели пункт 4 нереален...

[Прохожий]

ИМХО в твоей модели пункт 4 нереален...

Аргументируй ;) Он нереален для мелкомасштабных систем, где уровень автоматизации низок, отношения - "человеческие", и все друг друга знают в лицо. В системах крупного масштаба все именно так и происходит: workorder => исполнение => контроль.

[karpa13a]

Предлагаю следующую модель, представьте себе, что Вам предложены следующие условия:

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

 

При таком наборе условий каков был бы профиль работы в терминах удельного числа п. 4 и п. 5 на единицу оборудования

за прошлый год, по фактам исключительно факапов железа, получается 0.2 на устройство в год.

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

 

Меньше 48U не отгружается ;)

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

наружу линки? возможности доступа к бгп конфигам при аренде?)

AS дают в нагрузку?)

имя ему хецнер?)

 

ИМХО в твоей модели пункт 4 нереален...

реален. и практикуется.

[Дятел]

P.S. Нет, я не собираюсь делать ДЦ в военном бункере или на закрытой территории за колючей проволокой. Хотя мысль забавная :)

 

Как раз в новостях: "Все оборудование DE-CIX рассредоточено в защищенных помещениях франкфуртского метро" ))

[visir]

ИМХО в твоей модели пункт 4 нереален...

Аргументируй ;)

Скажем так, целиком линейную карту заменить - это без проблем. А вот "заменить на этой плате дочернюю плату типа XX номер YY, ну воон ту в верхнем правом углу чуть левее платы ZZ" - с этим уже сложнее, могут пойти в отказ мол "никогда такого не делали, оборудование сложное и дорогое, боимся повредить, присылайте своего техника".

Впрочем, если речь про однотипные серваки, которыми забит весь ДЦ - с этим проще, наверно.