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

  • Тихая революция: флеш-память в дата-центрах
    +1
    Флешовые СХД действительно лучше всего отрабатывают вложенные деньги под нагрузкой — чем она выше, тем ниже стоимость каждой транзакции. Про износ я упоминал, обычные HDD при аналогичных условиях ломаются куда чаще чем модули флеш-памяти.
  • Тихая революция: флеш-память в дата-центрах
    0
    Согласен, что-то есть ) Это Violin Memory V6000, по-своему, очень красивая штука.
  • Flash-память в дата-центрах: почему она иногда дешевле жестких дисков?
    0
    Статья действительно задумывалась как обзорная. Вопросы, которые вы затронули, весьма интересны и будут освещены в следующем посте. В нем я планирую рассказать про использование флеш-СХД с реальными приложениями. Если вам в голову придут еще какие-то моменты, про которые нужно упомянуть — пишите.
  • Flash-память в дата-центрах: почему она иногда дешевле жестких дисков?
    0
    Да, бита, рука дрогнула ) В коропоративных СХД преимущественно SLC используются, хотя сейчас часто и MLC можно встретить.
  • Flash-память в дата-центрах: почему она иногда дешевле жестких дисков?
    +1
    Совершенно верно, ячейки флеш-памяти имеют ограниченный ресурс записей – около 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 года или меньше.
  • Катастрофоустойчивые IT-системы: как внедрить в своей компании
    +2
    Совершенно справедливый комментарий, спасибо. В этом посте я не затрагивал очень важную тему построения отказоустойчивых сетей LAN, WAN, SAN между ЦОДами. Постараюсь написать об этом один из следующих постов.
    Ситуация с авариями как детонаторами перемен мне знакома. Если руководство воспринимает только это — важно предлагать варианты решения по горячим следам, не ждать, пока время вылечит. Непосредственно с Корбиной и Скартелом/Yota не работал, кстати.
    Очень важен общий уровень риск-менеджмента в компании и взаимодействия профильного подразделения с ИТ. Во некоторых наших бурно растущих бизнесах процессы отстают от масштаба деятельности. Я считаю, что донести до риск-менеджеров и руководства в целом мысль о важности инвестиций в непрерывность бизнеса можно. Главное, как следует подготовиться — собрать примеры последствий отказов у ваших конкурентов и в вашей собственной инфраструктуре, попытаться грубо оценить стоимость простоя. Взглянуть на ситуацию со стороны бизнеса, одним словом.
  • Катастрофоустойчивые IT-системы: как внедрить в своей компании
    +3
    Это действительно обзорный пост. Посмотрев на обратную связь, я планировал более подробно написать о некоторых из упомянутых решений подробно, в контексте референсных архитектур. Что касается конкретного кейса с HA-кластерами, описанный мной сценарий возможен, в случае того же VPLEX. Условием корректной отработки полного отказа ЦОДа со стороны VPLEX (т.е. подсистемы хранения данных, с точки зрения сервера) является наличие специальной виртуальной машины-наблюдателя, где-то в третьей локации. Она видит по IP контроллеры VPLEX в обоих ЦОДах, и позволяет отличить ситуацию отказа коммуникаций между двумя ЦОДами (когда внутри площадки все живо), от отказа ЦОДа целиком. Если контроллер не видит своего собрата, но видит наблюдателя и со стороны наблюдателя картина та же — все тома забираются в выживший ЦОД. В случае SVC возможен такой же наблюдатель, но он должен видеть все узлы по оптике. Другой вопрос, что в жизни могут быть нарушены и коммуникации с третьей площадкой-наблюдателем. Всегда возможна ситуация, когда самый продуманный кластер не отработает. Надо просто выбрать наилучшую технологию из имеющихся на рынке.
    При всем при этом, ценность любого геокластера в «ручном» режиме работы не намного меньше, чем в автоматическом. Отказы ЦОДов целиком случаются редко, главное, чтобы когда человек разобрался, что делать и принял решение — его выполнение прошло максимально быстро. Оснобенно, когда надо переводить на резервную площадку десятки систем. Десятки минут простоя при этом абсолютно нормальны, главное, чтобы они не превратились в многие часы и дни.
  • План аварийного восстановления — уверенность в завтрашнем дне для всей компании и спокойный сон ИТ-отдела
    +3
    Хорошо, в следующем топике будет пошаговое руководство по основным моментам.