НАЗВАНИЕ ПРЕЗЕНТАЦИИ

ИМЯ АВТОРА

Найбільший український спеціалізований IT-дистрибутор

Системы хранения данных от IBM.

Новая архитектура.

Шиндак Юрий

XIV Storage Systems

Система нового поколения.

Простое внедрение ресурсов,

возможности снижения затрат

на локальную репликацию,

питания, охлаждения и места

XIVОтличия архитектуры

Монолитный управляющий блок

Центральная разделяемая кеш

Нужна хорошая полоса пропускания между кешем и дисками

Сложное управления бокировками

Масштабируется независимо объем и

компоненты управляющего блока

XIV Virtualized Storage

Software

vs.

“Grid” из независимых модулей

Распределенная кеш-память

Высокая полоса пропускания между процессором-кеш-дисками

Сбалансировано масштабируется

Система хранения IBM XIV в деталях

Аппаратная часть IBM XiV

Три варианта: 15 модулей Full, 6 модулей Partial и от 2 до 15 CoD, по 12 драйвов в каждом

вариант Full - 6 из 15 имеют 4 x 4Гб FC, при этом 3 из 6 имеют 2 x 1Гб iSCSI

24 порта 4Гб FC

6 портов 1Гб iSCSI

120ГБ памяти (15 x 8ГБ)

3 x UPS

180ТБ «сырых»; 79ТБ «чистых» (1ТБ диски)

Глобальный резерв – полный модуль плюс 3 диска

79ТБ = (180 – 12 – 3 )/2 – 3.5 (для внутреннего использования)

Поддержка и сервис IBM

1 год, ответ через 4 часа, 24x7 Same Day On-Site Repair

Установка инженером IBM

оповещения по SMS, e-mail, VPN, modem

2 Ethernet

коммутат-

ора

15 модулей

3 UPS

системы

Архитектурные особенности масштабирования системы

Система может расти от 1 до 4-х шкафов *)

10GbE backbone interconnects multiple racks

Каждый модуль имеет собственный процессор и кеш-память

При добавлении модуля происходит наращивание:

Дисковой памяти

Размера кеш

Полосы пропуская кеш – диски и кеш-хосты

Процессорная мощность для управления

кеш-памятью

Производительность создания снепшотов

Виртуализация

Система IBM XIV использует уникальную технологию распределения данных

Каждый логический том распределен по всем дискам

Данные «разбиты» на «части» величиной 1MB, которые сохраняются на

дисках

Алгоритм XIV автоматически распределяет части по всем дискам псевдо-

случайным образом

Data Module

Interface

Data Module

Interface

Data Module

Interface

Switching

Технология распределения данных –изменения

Распределение данных меняется только при изменениях системы

Баланс сохраняется при добавлении модулей расширения

Баланс сохраняется при удалении модулей

Баланс сохраняется при сбоях

Node 2

Node 3

Node 1

Data Module 2Data Module 1

Data Module 3

Node 4

Data Module 2

Data Module 3

Data Module 1

[ hardware upgrade ]

Data Module 4

Распределение данных меняется только при изменениях системы

Баланс сохраняется при добавлении модулей расширения

Баланс сохраняется при удалении модулей

Баланс сохраняется при сбоях

Технология распределения данных –изменения

Технология распределения данных – изменения

Data Module 2

Data Module 3 Data Module 4

Data Module 1

[ hardware failure ]

Распределение данных меняется только при изменениях системы

Баланс сохраняется при добавлении модулей расширения

Баланс сохраняется при удалении модулей

Баланс сохраняется при сбоях

Концепция «Горячей Замены»

Как это сделано в IBM XIV

Время восстановления: 30 минут для 1ТБ диска (полностью)

Никаких выделенных дисков «горячей замены», только глобальная дополнительная емкость

Все диски используются одинаково

Минимизируются риски ошибок технического персонала

Высочайшая аппаратная надежность без снижения производительности

180ТБ «сырых» равны 79ТБ «чистых»

Запасная емкость на сбой 3 дисков и целого модуля

79ТБ = (180 – 12 – 3 )/2 – 3.5 (для внутреннего пользования)

Традиционный подход

Выделенные диски «горячей замены»

Во многих системах диски «горячей замены» выделяются отдельной RAID

группе

Снепшот создается/удаляется моментально Необходимо только 150мс... для любого размера

Снепшоты не влияют на производительность системы

Неограниченное количество

Дифференциальные снепшоты позволяют сохранить 15-30% емкости

Возможно создание снепшота со снепшота (а также клонов данных)

При создании снепшота в памяти создаются

ссылки на оригинальный том. Memory only

Operation

Когда хост пишет данные, они случайным

образом распределяются по системе

порциями по 1MB

Каждый узел в памяти хранит указатели

на данные, которые хранятся на

локальных дисках дисках

Восстановление тома из снепшота

Data ModuleData Module

Data ModuleData Module

Nextra Physical View

Функционал создания снепшотов IBM XIV

VolSnap

Snap

Распределенный снепшот на каждом

узле. Очень быстрая операция в

памяти.

Доступ к снепшоту такой же быстрый,

как и к продуктивному тому.

Высокопроизводительный снепшот

позволяет:

• Быстрый бекап на ленту

• Моментальное восстановление

• Быстрое и простое создание среды Test

and Dev.

• Boot-from-SAN с быстрым rollback

• Аналитику на реальном наборе данных

Thin Provisioning

Пользователи определяют тома любой величины

Получают только физические объемы, которые необходимы для записи

данных

– Та часть тома, которая не содержит данных, не потребляет дисковые

ресурсы

Actual

Data

Written

10GB

Actual

Data

Written

30GB

Actual

Data

Written

20GB

Volume

30GB

Volume

50GB

Volume

70GB

Fat provisioned Thin provisioned

Amount of physical

storage required

Actual

Data

Written

10GB

Actual

Data

Written

30GB

Actual

Data

Written

20GB

Volume

30GB

Volume

50GB

Volume

70GB

150 GB

60 GB

Управление. Инструменты.

Миграция данных

XIV имеет встроенную возможность миграции данных со старых

систем

Процесс требует минимальный простой

Legacy Storage

i.e. EMC, HDS,

NetApp,IBM

New XIV

Switch

Host

Migrate

Миграция данных

1. Установить новую систему XIV +

установить соединения

2. Установить соединения для миграции

3. Определить XIV как хост для старой

системы

4. Создайте целевой том

5. Погасить хост

6. Изменить зонирование

7. Смонтировать том-источник нf XIV

8. Начать миграцию.

9. Снова запустить хост

1.Миграция происходит в фоновом

режиме

10. Когда миграция закончится,

необходимо убрать скорость

Legacy

Storage

Switch

Host

XIV

Migrate

Выполняется несколько минут

Реальная банковская система

Задача

7ТБ Oracle Database для регистрациитранзакций (compliance)

Чрезвычайно высокие требования производительности

Безуспешно пытались внедрить DMX

Сохранение в «горячем режиме» невозможно на существующих системах

Решение

Система XIV с оптимальной утилизацией драйвов и эффективной емкостью логических копий

Преимущества и выгоды

Достигнута высочайшая скорость

обработки транзакций по сравнению с

другими Hi-End системами

Можно делать сохранение в «горячем

режиме» без ощутимых потерь

производительности

– Сейчас 4 ежедневных копии для

сохранения

– Копии хранятся в течение недели

– Можно восстановиться с любой из 28 копий

Высокая производительность,

Эффективное использование

логических копий

Банк Leumi

А Ваша система сможет так?

Сама себя восстанавливает и оптимизирует

Данные распределены по всем шпинделям

Восстановление 1ТБ диска < 30 минут!

Динамическое добавление новой емкости + ре-балансировка

Внедрение массива на пол-дня!

Провизионинг новых ресурсов хранения данных < 1 минуты

Обеспечение набора стандартных возможностей:

Практически неограниченное количество снепшотов

Thin provisioning

Удаленная репликация

Миграция данных

Простой менеджер устройства

Raid

Groups

Disk

TuningComplex

Mgmt.