2. XIV Storage Systems
Система нового поколения.
Простое внедрение ресурсов,
возможности снижения затрат
на локальную репликацию,
питания, охлаждения и места
3. XIV
Отличия архитектуры
Монолитный управляющий блок
Центральная разделяемая кеш
Нужна хорошая полоса пропускания
между кешем и дисками
Сложное управления бокировками
Масштабируется независимо объем и
компоненты управляющего блока
XIV Virtualized Storage
Software
vs.
“Grid” из независимых модулей
Распределенная кеш-память
Высокая полоса пропускания между
процессором-кеш-дисками
Сбалансировано масштабируется
4. Система хранения 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
системы
5. Архитектурные особенности масштабирования
системы
Система может расти от 1 до 4-х шкафов *)
10GbE backbone interconnects multiple racks
Каждый модуль имеет собственный процессор и кеш-память
При добавлении модуля происходит наращивание:
Дисковой памяти
Размера кеш
Полосы пропуская кеш – диски и кеш-хосты
Процессорная мощность для управления
кеш-памятью
Производительность создания снепшотов
6. Виртуализация
Система IBM XIV использует уникальную технологию распределения данных
Каждый логический том распределен по всем дискам
Данные «разбиты» на «части» величиной 1MB, которые сохраняются на
дисках
Алгоритм XIV автоматически распределяет части по всем дискам псевдо-
случайным образом
Data Module
Interface
Data Module
Interface
Data Module
Interface
Switching
7. Технология распределения данных –
изменения
Распределение данных меняется только при изменениях системы
Баланс сохраняется при добавлении модулей расширения
Баланс сохраняется при удалении модулей
Баланс сохраняется при сбоях
Node 2
Node 3
Node 1
Data Module 2Data Module 1
Data Module 3
8. Node 4
Data Module 2
Data Module 3
Data Module 1
[ hardware upgrade ]
Data Module 4
Распределение данных меняется только при изменениях системы
Баланс сохраняется при добавлении модулей расширения
Баланс сохраняется при удалении модулей
Баланс сохраняется при сбоях
Технология распределения данных –
изменения
9. Технология распределения данных – изменения
Data Module 2
Data Module 3 Data Module 4
Data Module 1
[ hardware failure ]
Распределение данных меняется только при изменениях системы
Баланс сохраняется при добавлении модулей расширения
Баланс сохраняется при удалении модулей
Баланс сохраняется при сбоях
10. Концепция «Горячей Замены»
Как это сделано в IBM XIV
Время восстановления: 30 минут для 1ТБ диска (полностью)
Никаких выделенных дисков «горячей замены», только глобальная
дополнительная емкость
Все диски используются одинаково
Минимизируются риски ошибок технического персонала
Высочайшая аппаратная надежность без снижения производительности
180ТБ «сырых» равны 79ТБ «чистых»
Запасная емкость на сбой 3 дисков и целого модуля
79ТБ = (180 – 12 – 3 )/2 – 3.5 (для внутреннего пользования)
Традиционный подход
Выделенные диски «горячей замены»
Во многих системах диски «горячей замены» выделяются отдельной RAID
группе
11. Снепшот создается/удаляется моментально
Необходимо только 150мс... для любого размера
Снепшоты не влияют на производительность системы
Неограниченное количество
Дифференциальные снепшоты позволяют сохранить 15-30% емкости
Возможно создание снепшота со снепшота (а также клонов данных)
При создании снепшота в памяти создаются
ссылки на оригинальный том. Memory only
Operation
Когда хост пишет данные, они случайным
образом распределяются по системе
порциями по 1MB
Каждый узел в памяти хранит указатели
на данные, которые хранятся на
локальных дисках дисках
Восстановление тома из снепшота
Data Module
Data Module
Data Module
Data Module
Nextra Physical View
Функционал создания снепшотов IBM XIV
Vol
Snap
Snap
Распределенный снепшот на каждом
узле. Очень быстрая операция в
памяти.
Доступ к снепшоту такой же быстрый,
как и к продуктивному тому.
Высокопроизводительный снепшот
позволяет:
• Быстрый бекап на ленту
• Моментальное восстановление
• Быстрое и простое создание среды Test
and Dev.
• Boot-from-SAN с быстрым rollback
• Аналитику на реальном наборе данных
12. 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
14. Миграция данных
XIV имеет встроенную возможность миграции данных со старых
систем
Процесс требует минимальный простой
Legacy Storage
i.e. EMC, HDS,
NetApp,IBM
New XIV
Switch
Host
Migrate
15. Миграция данных
1. Установить новую систему XIV +
установить соединения
2. Установить соединения для миграции
3. Определить XIV как хост для старой
системы
4. Создайте целевой том
5. Погасить хост
6. Изменить зонирование
7. Смонтировать том-источник нf XIV
8. Начать миграцию.
9. Снова запустить хост
1.Миграция происходит в фоновом
режиме
10. Когда миграция закончится,
необходимо убрать скорость
Legacy
Storage
Switch
Host
XIV
Migrate
Выполняется несколько минут
16. Реальная банковская система
Задача
7ТБ Oracle Database для регистрации
транзакций (compliance)
Чрезвычайно высокие требования
производительности
Безуспешно пытались внедрить DMX
Сохранение в «горячем режиме»
невозможно на существующих системах
Решение
Система XIV с оптимальной утилизацией
драйвов и эффективной емкостью
логических копий
Преимущества и выгоды
Достигнута высочайшая скорость
обработки транзакций по сравнению с
другими Hi-End системами
Можно делать сохранение в «горячем
режиме» без ощутимых потерь
производительности
– Сейчас 4 ежедневных копии для
сохранения
– Копии хранятся в течение недели
– Можно восстановиться с любой из 28 копий
Высокая производительность,
Эффективное использование
логических копий
Банк Leumi
17. А Ваша система сможет так?
Сама себя восстанавливает и оптимизирует
Данные распределены по всем шпинделям
Восстановление 1ТБ диска < 30 минут!
Динамическое добавление новой емкости + ре-балансировка
Внедрение массива на пол-дня!
Провизионинг новых ресурсов хранения данных < 1 минуты
Обеспечение набора стандартных возможностей:
Практически неограниченное количество снепшотов
Thin provisioning
Удаленная репликация
Миграция данных
Простой менеджер устройства
Raid
Groups
Disk
Tuning
Complex
Mgmt.