Создание виртуальных хранилищ данных с независимыми ресурсами внутри физического Hitachi VSP

добавлено: 12 июл 13
понравилось:0
просмотров: 2217
комментов: 9

теги:

Автор: ДохтаР

В продолжение темы
Прежде чем новых обитетелей зверинца датацентра
запустить в в вольеры доступные зрителям , зверям нужно проводить карантин.
И выяснить их живучесь в условия реального зверинца.

В качестве зверя на карантине имеем свежеустановленные flash накопители
внутри стораджа Hitachi VSP

Первое ,что мне хотелось бы выяснить насколько кеш стораджа влияет на производительность
лунов лежащих на flash накопителях .

Для выяснения этого момента на сторадже отрезаем 2 виртуальных стораджа
используя функционал Virtual Partition Manager ,
по умолчанию( без доп лицензирования)
система позволяет создать 4 виртуальных стораджа внутри одного физического
с перемещением ресурсов между виртуальными стораджами на лету.

Виртуальный сторадж №1
1. Раид группа 5-1 ( Raid5 3+1 состоящая из flash накопителей )
2. Обьема кеша 4Gb.
3. FC портов (2B,3B, 4B 1B).



Виртуальный сторадж №2
1. Раид группа 5-2 ( Raid5 3+1 состоящая из flash накопителей )
2. Обьема кеша 100Gb.
3. FC портов (2B,3B, 4B 1B).

Как вы заметили , оба виртуальных стораджа будут
шарить между собой FC порты (2B,3B, 4B 1B).
При необходимости мы их сможем разрезать потом,
то есть отдать по 2 независимых порта каждому стораджу.

Посмотрим что покажут тесты и если, что разделим.

собственно начнем ......


Вот что у меня получилось
Картинка с другого сайта.

Это обьем кеша в 4 Гб который будет использоваться системой при ввовде выводе
в парити группу 5-1.

При при создании меня чесно предупредили
Картинка с другого сайта.
Мне собственно это и нужно , что бы проверить супер-пупер быстрые накопители без кеша.


Второй полигон для тестирования

Картинка с другого сайта.
[/more]
тут мы имеем 100 Гб кеша и парити группу 5-2 .

Как вы заметили в конфигурации есть еще две кеш партиции ,
они используются продуктивной системой которая молотит 20 000 иопсов по ~50 шпинделям.
У партиции CLPR0 пришлось отобрать 100 гиг кеша, несколько дней назад весь сторадж имел
128 Гиг кеша , продуктивной системе этого хватало.
Вместе с FMD в систему было добавлено еще 128.

Возможно в будущем в отдельной статье я опишу по каким критериям и зачем
делить кеши в условия продуктивной нагрузки.

Весь этот длинный рассказ к тому,
что процеруда отрезания 100 Гб кеша налету из CLPR0 по которому молотят
живые иопсы заняла около 40 минут, что считаю нормальным.

Каждая группа побита на 12 лунов ( томов) которые мы потом
будем презентовать хостам.
1000 Gb - 1 шт
100 Gb - 10 шт
2915.18 - 1 шт.

Картинка с другого сайта.

Хостам презентовано по 13 лунов , нулевой лун загрузочный , в теситировании участвовать не будет.

Картинка с другого сайта.

Комментарии


  • Хитачевский хайенд схд, да это ужос тихий... Мы слава богу ушли с них и слава богу!

  • xxxkms, и на чем вы остановили ваш выбор?
    если не секрет.

  • 14 июля 2013, 23:13 Ихтиандр

    Нормальный хайенд.
    А зачем тестировать?
    Реальных задач, которым была необходима суперпроизводительность нет?

  • Есть сайзинг , есть задачи, и сроки запуска есть.

    Хочется понять, реальную,
    а не маркетинговую сущьность железа.
    поэтому и создаются конфигурации для чистого
    эксперемента.

  • xxxkms, извини, я случайно грохнул твое последнее сообщение.

    Перепость его пожалуйста ,
    Я собственно на него ответ хотел написать следующего плана.

    То что писано в этой статье ( разделение стораджа на виртуальные стораджи ) по кешу и рейд группам и портам я в функционале IBM Storwize V7000 не нашел.
    Можешь дать ссылку, как двум серверам живущим на одном сторадже сделать непересакающиеся ресурсы , что бы они их друг у друга не забирали , например что бы сервер
    делающий секвеншал-паралел-райт не выбивал кеш стораджа у сервера который пишет и читает поблочно на ИОПС и имеет более высокие требования по латентности ответа от системы ввода вывода
    .

    Еще раз прости.

  • Вот этого там нет, все таки V7000 это midrange схд, а фишки с приоритезацией кеша, пропускной портов ввода-вывода это прирогатива hi-end СХД. Увы...

  • xxxkms, собственно так как у меня эта фича активно используется в продукиве, и хорошо себя показывает, например для случая, что бы архивация и бекап оракловых арклогов не выбивала стораджовый кеш под датафайлами.

    Я не рассматриваю альтернативные стораджи,
    не имеющие такого функционала для приложений уровня предприятия где нужно обеспечивать гарантированное время отклика системы .
    Какой бы красивый и удобный интерфейс они не имели.

  • Мы делаем проще, для каждой задачи своя отдельная СХД. Никаких взаимных влияний и забиваний кеша, и гораздо дешевле чем один большой хайэнд.

  • xxxkms , ваш подход понятен,
    В нашем случае системы могут расти по разному и по разному использовать ресурсы, в разные периоды времени. поэтому мы в любой момент можем забрать ресурсы у одной системы отдать другой, а потом вернуть обратно.
    Функционал виртуальных стораджей дает мобильность в принятиях решения по обеспечению перфоменса.

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



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