Да это на сколько стальные яйца должны быть, чтобы на проде у заказчика так делать )

Влад, записи не могут параллелиться по ядрам. Если эта БД это основной источник нагрузки на СХД, то разбивайте на количество Лунов/Вольюмов равное количеству ядер на СХД, особенно если много операций записи. Тогда нагрузка от записи будет более равномерно распределяться по ядрам ЦПУ СХД.

Хотя даже если БД не является основным источником нагрузки, такой подход с количеством лунов/вольюмов равный количеству ядер, ничего плохого с точки зрения перфоменса не сделает, по этому его можно использовать везде.

PS каждый вольюм, это отдельный поток записи. Вольюм, не лун!

Мозговой штурм подразумевает рассмотрения всех доступных вариантов.

Я так делал с двумя дисками, у меня прокатило. Плюс два диска это количество парити, так что если бы они отвалились, то рейд не развалится. А на ONTAP 9.1 можно на ходу DP переделать в RAID-TEC (и обратно), будет 3 диска четности. Так что это тоже вполне себе вариант.

Кстати это меня наводит на мысль об ещё одном сумасшедшем варианте. Можно hot spare диски разместить в новой полке и по одному диску вытягивать чтобы рейд перестраивался. Минусы такого варианта 1) дополнительная нагрузка на агрегат от перестройки рейд. 2) долгое время. Соответственно этот вариант для маленьких агрегатов. Но первый вариант на много быстрее, там нужно переставлять по одному диску, выжидать когда система его увидит, а если он даже отвалиться, то есть парити.

Спасибо! Но создавая 1 лун или 4 лина (по 2 на контроллер) мы наблюдали нагрузку по всем ядрам в потолок, а не 1 я дро или 2 на каждом контроллере.

Это смотря какой командой вы это наблюдали ;)

Ну с ребилдом - это дичь. Но мысль вставить в стек новую полку, находу переткнуть поочередно в неё диски, а потом вытащить из стека старую - ничего так )

Если агрегат состоит из 2-3 дисков, то это тоже вариант.

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

Сделали по 8 лунов на каждом контроллере, тоесть 8 лунов (по 4 на контроллер) для базы MAIN, как основного репозитория данных, и по 4 луна с каждого контроллера для TEMP (временный срез части данных с main, который создается по запросу подльзователя, по окончанию работы этого же пользователя с ним он очищается). Общее количество, выделенное для базы - 2,8ТБ. Вообщем результат следующий: процессоры контроллеров нагружены на 40% в среднем, пропускная способность 1200МБ/с , латентность 2мс. Наблюдается  утилизацмя 2-х камней по 16 ядер на хосте, соответственно есть подозрение что хост больше не нагрузит. Будем пробывать навешивать более мощный сервак. Как-то так.

Перфстатом собрал архив, как ты и учил!)

Ты там смотришь на “sysstat просто” или «sysstat -M”?
Есть разница

И утилизация 2х ядер таки на ЦПУ хоста или таки на ЦПУ СХД?
Потому что я говорю про ЦПУ СХД.

А какая-то модель AFF, сколько дисков, версия ONTAP, протокол?

Коллеги,вопрос тупой но все же. 2552 - 1 лун и волюм, подключена к vsphere. Сделали большую толстую машину, которая отьела в е место на полке. Машину удалили, vsphere показывает что место на датасторе полно, а в полке места нет. Сто будет если записисать большой файл?

Удалите снепшоты

Их нет, они отключены

Так вольюм сам по себе растянулся от виртуалки и занимает место на полке, а внутри пустой.

Ничего не будет. На хостах VMware надо включать опцию EnableBlockDelete

Лун должен быть тонкий. И у него надо включать space-allocation через консоль.

Ребята, привет. Нужны скрины по производительности Fas2650 с гибридной полкой при работе Sql, профиль 30/70. Можете поделиться? Владелец систем не важен.

Sysstat -M смотрю