ETERNUS DX — новая версия микрокода

    Как уже отмечалось ранее, ETERNUS DX – это действительно единая продуктовая линейка, поэтому, как правило, и новые версии микрокодов появляются тоже одновременно для всех моделей линейки. Посмотрим, что нового появилось в последнее время для систем ETERNUS DX80/90/410/440/8700 S2. Для всех этих систем апдейт на последнюю версию микрокода добавляет следующие «фичи».:

    1) Поддержку интерфейсных карт FC 16 Gbs. Возможно, сегодня не самый часто спрашиваемый интерфейс, но, раз Brocade начал активное продвижение своих коммутаторов на 16 Gb, то нет сомнения что через год большинство проектов для FC будет уже идти на 16 Gb. Тем не менее, при желании с февраля эти карты доступны к заказу.

    2) Поддержка размера кэша более 1 ТБ для ETERNUS DX8700 S2.

    3) Для механизма Quality of Service добавлен собственный планировщик задач (Scheduler).

    4) При желании можно отключить зеркалирование кэша. Понятно, что никто не будет такого рекомендовать для критически важных конфигураций. Конечно, при установке рекордов по производительности в SPC-1 и SPC-2 кэш никто не отключал. Но, тем не менее, сегодня заказчик имеет опцию увеличения производительности ценой снижения надежности системы. Есть ряд приложений, где производительность важнее возможного риска потери данных. Понятно, что по умолчанию эта опция выключена.

    5) Secure Erase/LUN shredding – дополнительная возможность удалить логический том с принудительным и гарантированным действительным удалением всей информации на томе средствами самого массива.

    6) Можно создавать логические тома нового типа WSV (Wide Striping Volume). Вот это действительно интересная новая возможность, которая позволяет «размазать» один логический том между несколькими RAID-группами. Причем это не обычное «склеивание» LUN из двух логических томов, а именно поочередное использование блоков из нескольких RAID-групп. Например, при выполнении операции чтения с дисков мы будем использовать все диски всех RAID-групп, на которых расположен WSV-том. Фактически, эта технология позволяет средствами самого массива существенно увеличить производительность для одного конкретного логического тома. Аппаратные ресурсы выделенных жестких дисков и обоих контроллеров будут в полной мере использоваться для того, чтобы максимально увеличить производительность работы конкретного логического тома. Понятно, что есть ряд ограничений и best practice. Например, не самая хорошая идея делать WSV между RAID-группами, которые лежат на разных типах дисков или в разном уровне RAID.

    7) Zero Reclamation для томов Thin Provisioning.

    8) Поддержка и тесная интеграция Thin Provisioning самого массива с Thin Provisioning Windows Server 2012.

    9) Поддержка технологии ODX (Offloaded Data Transfer) для Windows Server 2012. Реально это аналог VAAI для VmWare (который, кстати, давно уже поддерживается), но для Hyper-V.

    10) Cache Partitioning – возможность ограничения максимального размера кэша, который будет выделен для того или иного логического тома.

    11) Поддержка long wave SFP+. Теперь, установив эти SFP, можно разнести собственно массив от коммутатора или хоста на 4 километра. Может, кстати, получиться весьма дешевое и эффективное решение по увеличению надежности всей системы, – взять и установить дисковый массив в соседнем здании.

    12) Поддержка IPv6.

    13) Поддержка Internet Explorer 10 как web-браузера для мониторинга или управления.

    14) Поддержка до 256 сессий моментальных снимков SnapOPC c одного источника.
    Fujitsu 57,16
    Японская компания-лидер ICT-рынка
    Поделиться публикацией
    Комментарии 3
    • 0
      Спасибо за обзор прошивки.
      1) Поддержку интерфейсных карт FC 16 Gbs.

      Какие решения в вашей линейке такие интерфейсы раскрывают? Мне кажется это интересно только на операциях большим блоком. Иначе будем упираться просто в очереди на контроллере. Нет?
      14) Поддержка до 256 сессий моментальных снимков SnapOPC c одного источника.

      Есть нагрузочное тестирование данной технологии? Тестировал подобное от Hitachi — так себе оказалось, производительность не применябельная.
      • 0
        1) Понятно, что с системы начального уровня загрузиь такой интерфейс сложно. Даже 8 Gbs — сложно. Но практика показывает, что иногда можно :). Поддерживаются эти адаптеры во всех массивах, начиная с DX80 и заканчивая DX8700. Всяко лучше упираться в очереди на контроллере, чем в очереди на передаче на свиче. Опять же, есть сценарии когда большой процент данных на этапе чтения уже есть в кэше (а кэша в системах много), тогда тоже.
        Другой аспект — новые коммутаторы Brocade на 16 Gbs, которые мы тоже поставляем как ОЕМ-партнер. В них действительно ожидается очень серьезный рывок по производительности на уровне нового ASIC. Ну и логично, что если будет происходить постепенный переход на 16 Gbs во всем SAN, то и массив тоже на 16 подключить
        14) Это уже напрямую зависит от того, как динамично данные меняются. Опять же, 256 сессий моментальных снимков с одного источника уже само по себе нетривиальная задача по администрированию. Есть внутренние результаты применения данной технологии для разных массивов и разных сценариев загрузки, в том числе и с разным количеством моментальных снимков. Но это внутренние документы, не для публикации. Активно используем при сайзинге решений для заказчиков в конкретных условиях. Опять же, есть возможность всегда взять реальный массив и попробовать в действии. Если есть конкретный интерес по конкретному проекту — обращайтесь в представительство, постараемся помочь.
        • 0
          1)
          Даже 8 Gbs — сложно.
          Да ладно, я прогружал до десятка портов(или может больше, уже не помню). Классные скриншоты iostat остались на память :D
          14) Про рост — это понятно. Я делал вот такое простенькое тестирование. Можно самому сделать, но это время… Конкретного проекта под данную технологию нет, интерес носит сугубо частный характер.

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

      Самое читаемое