Pull to refresh
25
0
Дмитрий Дощаный @Dmitry_Doshaniy

User

Send message

Спасибо, Саша, знатно поностальгировал. Будет время и свои байки из тех и еще более ранних времен напишу) Была романтика в северном и схдшном железе

8000 Петабайт на 120Тб, на 12Тб — 800 Петабайт.
Предполагается что в одной ячейке 128Кб а не 128 х 4Кб, хотя тут по разному у разных производителей.
Мой расчет подразумевает последовательную запись – в лог-файлы и архивные логи.
Вообще, считать такие вещи теоретически – дело довольно неблагодарное, я лишь привел пример. Ресурс флеш-памяти разный у разных производителей и даже у одного производителя в рамках одной партии, обычно выше заявляемого. Профиль нагрузки тоже в реальности трудно предсказуем. Если обратиться к фактам, та же Violin Memory на свои SLC-массивы дает гарантию 5 лет, время жизни декларирует 10 лет и 8000 Петабайт записей.
Первый график – зависимость количества записей (IOPS) от времени.
Второй – зависимость времени отклика дисковой подсистемы (мс) от времени суток.
Вопрос действительно важный, с учетом того что все больше заказчиков арендуют ЦОДы и экономия стойкомест выражается в реальных деньгах. Места флешовые СХД занимают в разы меньше. Как пример от одного западного заказчика – 6 юнитов вместо 150 и в шесть раз меньшее энергопотребление.

Флешовые СХД действительно лучше всего отрабатывают вложенные деньги под нагрузкой — чем она выше, тем ниже стоимость каждой транзакции. Про износ я упоминал, обычные HDD при аналогичных условиях ломаются куда чаще чем модули флеш-памяти.
Согласен, что-то есть ) Это Violin Memory V6000, по-своему, очень красивая штука.
Статья действительно задумывалась как обзорная. Вопросы, которые вы затронули, весьма интересны и будут освещены в следующем посте. В нем я планирую рассказать про использование флеш-СХД с реальными приложениями. Если вам в голову придут еще какие-то моменты, про которые нужно упомянуть — пишите.
Да, бита, рука дрогнула ) В коропоративных СХД преимущественно SLC используются, хотя сейчас часто и MLC можно встретить.
Совершенно верно, ячейки флеш-памяти имеют ограниченный ресурс записей – около 100.000 на ячейку для SLC. Но ячейка SLC хранит всего 1 байт информации, MLC – два байта.
Контроллеры SSD-дисков (как и обычных флешек, кстати) отвечают за равномерное распределение записей (а следовательно – износа) по всему объему флеш-памяти — механизм wear leveling (http://en.wikipedia.org/wiki/Wear_leveling). В случае специализированных «флешовых» СХД, равномерный износ распределяется по всему объему массива и занимаются этим контроллеры СХД. SSD-диски обычно имеют до 25% емкости в резерве, чтобы вводить в строй вместо отживших ячеек.
Если каждый байт можно перезаписать 100.000 раз, то 100 гигабайт «сотрутся» за 8 лет при непрерывной записи (24 х 7 х 365) на скорости 5000 IOPS (блоки 8 килобайт). Один из производителей флешовых СХД говорил при встрече, что на их системах, которые работают в высоконагруженных средах уже 2-3 года, износ не превышает 1%. Они, кстати, дают на все системы гарантию 5 лет. На традиционные СХД срок 3 года или меньше.
Совершенно справедливый комментарий, спасибо. В этом посте я не затрагивал очень важную тему построения отказоустойчивых сетей LAN, WAN, SAN между ЦОДами. Постараюсь написать об этом один из следующих постов.
Ситуация с авариями как детонаторами перемен мне знакома. Если руководство воспринимает только это — важно предлагать варианты решения по горячим следам, не ждать, пока время вылечит. Непосредственно с Корбиной и Скартелом/Yota не работал, кстати.
Очень важен общий уровень риск-менеджмента в компании и взаимодействия профильного подразделения с ИТ. Во некоторых наших бурно растущих бизнесах процессы отстают от масштаба деятельности. Я считаю, что донести до риск-менеджеров и руководства в целом мысль о важности инвестиций в непрерывность бизнеса можно. Главное, как следует подготовиться — собрать примеры последствий отказов у ваших конкурентов и в вашей собственной инфраструктуре, попытаться грубо оценить стоимость простоя. Взглянуть на ситуацию со стороны бизнеса, одним словом.
Это действительно обзорный пост. Посмотрев на обратную связь, я планировал более подробно написать о некоторых из упомянутых решений подробно, в контексте референсных архитектур. Что касается конкретного кейса с HA-кластерами, описанный мной сценарий возможен, в случае того же VPLEX. Условием корректной отработки полного отказа ЦОДа со стороны VPLEX (т.е. подсистемы хранения данных, с точки зрения сервера) является наличие специальной виртуальной машины-наблюдателя, где-то в третьей локации. Она видит по IP контроллеры VPLEX в обоих ЦОДах, и позволяет отличить ситуацию отказа коммуникаций между двумя ЦОДами (когда внутри площадки все живо), от отказа ЦОДа целиком. Если контроллер не видит своего собрата, но видит наблюдателя и со стороны наблюдателя картина та же — все тома забираются в выживший ЦОД. В случае SVC возможен такой же наблюдатель, но он должен видеть все узлы по оптике. Другой вопрос, что в жизни могут быть нарушены и коммуникации с третьей площадкой-наблюдателем. Всегда возможна ситуация, когда самый продуманный кластер не отработает. Надо просто выбрать наилучшую технологию из имеющихся на рынке.
При всем при этом, ценность любого геокластера в «ручном» режиме работы не намного меньше, чем в автоматическом. Отказы ЦОДов целиком случаются редко, главное, чтобы когда человек разобрался, что делать и принял решение — его выполнение прошло максимально быстро. Оснобенно, когда надо переводить на резервную площадку десятки систем. Десятки минут простоя при этом абсолютно нормальны, главное, чтобы они не превратились в многие часы и дни.
Хорошо, в следующем топике будет пошаговое руководство по основным моментам.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity