Comments 12
Наличие проблем с проектированием ЦОД — недоработка программистов. Когда нормальные распределённые хранилища и NUMA наконец-таки станут мейнстримом, ЦОДы будут проектироваться исключительно по складским показателям. Проблемы с вентиляцией — отключайте нафиг, пользователи всё равно не заметят. Затопило? Беда-беда, компьютеры придётся заменить, но пользователи всё равно не заметили.
Не знаю, как у программистов, а у строителей все просто. Например, сортировочный холодильник мясных полуфабрикатов строят с уровнем
отказоустойчивости 100%, т.е. 0 минут простоя в год. Поставщики просто не могут позволить себе испортить 100 тон мяса глубокой
заморозки или даже изменить температуру хранения больше чем на 1 градус. Продукты — это материальная субстанция, их, как информацию, не перекинешь на другую площадку и даже не забекапишь, за то, в отличие от информации, их можно съесть, особенно если они свежие!
Так что требования к складам могут быть даже круче чем для ЦОДов!
Кстати, с Днем Строителей!
отказоустойчивости 100%, т.е. 0 минут простоя в год. Поставщики просто не могут позволить себе испортить 100 тон мяса глубокой
заморозки или даже изменить температуру хранения больше чем на 1 градус. Продукты — это материальная субстанция, их, как информацию, не перекинешь на другую площадку и даже не забекапишь, за то, в отличие от информации, их можно съесть, особенно если они свежие!
Так что требования к складам могут быть даже круче чем для ЦОДов!
Кстати, с Днем Строителей!
Молодец, сразу видно профессионала
А то понавыдумывают своих тиеров первых, тиеров третьих…
А то понавыдумывают своих тиеров первых, тиеров третьих…
В отсутствие готового технического решения без негативных вопросов — это проблема, да.
Кроме того, фактор стоимости железа остаётся вне зависимости от софта, то есть охрана/нормальное помещение без отопления «этажом выше» и приличное электричество (фильтрованное) будет востребовано в любом случае.
А вот availability, я надеюсь, постепенно выползет в район чистого ПО. Иначе гонка за терабайтами при энтерпрайзных ценах на более-менее надёжное — это путь в никуда.
Кроме того, фактор стоимости железа остаётся вне зависимости от софта, то есть охрана/нормальное помещение без отопления «этажом выше» и приличное электричество (фильтрованное) будет востребовано в любом случае.
А вот availability, я надеюсь, постепенно выползет в район чистого ПО. Иначе гонка за терабайтами при энтерпрайзных ценах на более-менее надёжное — это путь в никуда.
availability, я надеюсь, постепенно выползет в район чистого ПО
Поясните пожалуйста смысл сказанного.
Если имеется в виду, что часть приложений сможет использовать распределенные вычисления, то это далеко не все приложения. Есть Business-Critical приложения больших компаний. Разместив их, скажем, на 5-ти сайтах с доступностью T2 мы не получим даже доступность T3 (99,982%).
Т2 — это 99.741%, следовательно вероятность отказа одного ЦОД 0.259%.
Вероятность одновременного отказа всех 5 ЦОД будет равны вероятности отказа одного, возведенная в степень 5: 0.00116546388%.
Если вычесть из 100% полученное число, то итоговая надежность 5 ЦОД уровня Т2 будет равна 99.9988345361%, что даже больше, чем надежность Т4 ЦОДа.
Именно так и строят надежные системы из ненадежных компонент. Другое дело, что данный расчет не учитывает внешнюю связность, но стандарты ЦОДов ее тоже не учитывают если мне память не изменяет…
Вероятность одновременного отказа всех 5 ЦОД будет равны вероятности отказа одного, возведенная в степень 5: 0.00116546388%.
Если вычесть из 100% полученное число, то итоговая надежность 5 ЦОД уровня Т2 будет равна 99.9988345361%, что даже больше, чем надежность Т4 ЦОДа.
Именно так и строят надежные системы из ненадежных компонент. Другое дело, что данный расчет не учитывает внешнюю связность, но стандарты ЦОДов ее тоже не учитывают если мне память не изменяет…
Это не относится к данному расчету, но самое важное, почему такие формулы не работает в реальности, это стоимость инфраструктуры T2 и колоссальные эксплуатациионные расходы. Для того что бы формула работала нужно что бы все 5 ЦОДов имели мощность для охлаждения 100% IT нагрузки и UPS и т.п. (грубо), так же, систему электроснабжения (более 130% мощности IT нагрузки), серверы/СХД и вспомогательные системы. И их не получится ничем как бы занять на время простоя. С точки зрения бизнеса это будут деньги, закопанные с вероятностью более 99,7% бесполезно :)
Эти формулы на прямую не работают в реальности только из-за большей сложности создания распределенных систем и большего количества потенциальных подводных камней.
Стоимость решения — это критерий выбора стратегий обеспечения этой самой надежности. Либо мы строим один сверхнадежный ЦОД и миримся с тем, что он может упасть при удачном прямом попадании молнии или метеорита (или нападении экскаваторщиков, которые перекопали все окрестности) или строим несколько менее надежных площадок, разнесенных на некоторое расстояние, и обеспечивает нужный уровень девяток при помощи программных решений, зато можем пережить падение одной или нескольких площадок с плавной деградацией общей надежности системы, а не с резким ее скачком до 0%.
Стоимость решения — это критерий выбора стратегий обеспечения этой самой надежности. Либо мы строим один сверхнадежный ЦОД и миримся с тем, что он может упасть при удачном прямом попадании молнии или метеорита (или нападении экскаваторщиков, которые перекопали все окрестности) или строим несколько менее надежных площадок, разнесенных на некоторое расстояние, и обеспечивает нужный уровень девяток при помощи программных решений, зато можем пережить падение одной или нескольких площадок с плавной деградацией общей надежности системы, а не с резким ее скачком до 0%.
Есть такое business-critical приложение. База данных, от которой зависит работа бизнеса на десятки триллионов долларов.
Называется DNS. При всех своих недостатках, с начала своей работы он ни разу не «падал» (в описанной человеком истории). Хотя если посмотреть, на каком хламе некоторые части базы данных хранятся…
Называется DNS. При всех своих недостатках, с начала своей работы он ни разу не «падал» (в описанной человеком истории). Хотя если посмотреть, на каком хламе некоторые части базы данных хранятся…
Я просто не знаю, как рассчитать стоимость эксплуатации DNS и текущую надежность (конечно, всего сервиса DNS в совокупности). И какова реальная стоимость «хлама», включая расходы на электрич-во, охлаждения, место в стойке/на полу/под столом. Я не представляю, как сделать этот расчет. Предполагаю, что если даже часть этих расходов мала, в совокупности получится что-то очень дорогое.
Стоимость фантастическая. Если учесть стоимость персонала, обучения и т.д. — просто фантастическая.
Но и бизнес-ценность такова, что переоценить её невозможно. Ведь от работы этого приложения зависит каждый коммерческий сайт в интернете.
Кстати, сколько бы сравнительно (в процентах) стоил эквивалент в виде энтерпрайзного решения (дороже-больше-надёжнее) мне трудно прикинуть, но на глазок (то есть без каких-либо обоснований) я бы предположил что-то порядка 1:100 в пользу distributed.
Но и бизнес-ценность такова, что переоценить её невозможно. Ведь от работы этого приложения зависит каждый коммерческий сайт в интернете.
Кстати, сколько бы сравнительно (в процентах) стоил эквивалент в виде энтерпрайзного решения (дороже-больше-надёжнее) мне трудно прикинуть, но на глазок (то есть без каких-либо обоснований) я бы предположил что-то порядка 1:100 в пользу distributed.
Рассчитать стоимость эксплуатации и определить надежность действительно сложно, но возможно.
Первым делом проводится аудит на предмет текущего состояния, потом выполняется оценка по резервированию с прогнозированием рисков, а за тем описывается, что нужно сделать, чтобы данные риски хеджировать.
После этого можно считать стоимость, в т.ч. стоимость эксплуатации.
А вообще в ЦОДостроении дорого/дешево/много/мало — это все субъективные оценки, чтобы от них уйти и были придуманы стандарты Т1,2,3,4
А то получается, как в истории про теорию относительности. Одна блондинка во время обеда попросила Энштейна, объяснить ей теорию относительности. Он долго смотрел на нее и наконец ответил:
«- вот у меня на голове осталось всего три волосинки – это очень мало, но с другой стороны даже один волос в Вашем супе – это будет уже очень много …
Первым делом проводится аудит на предмет текущего состояния, потом выполняется оценка по резервированию с прогнозированием рисков, а за тем описывается, что нужно сделать, чтобы данные риски хеджировать.
После этого можно считать стоимость, в т.ч. стоимость эксплуатации.
А вообще в ЦОДостроении дорого/дешево/много/мало — это все субъективные оценки, чтобы от них уйти и были придуманы стандарты Т1,2,3,4
А то получается, как в истории про теорию относительности. Одна блондинка во время обеда попросила Энштейна, объяснить ей теорию относительности. Он долго смотрел на нее и наконец ответил:
«- вот у меня на голове осталось всего три волосинки – это очень мало, но с другой стороны даже один волос в Вашем супе – это будет уже очень много …
Sign up to leave a comment.
Риски ЦОД: выбираем месторасположение