Я ищу MD3620i SAN с 24 дисками для виртуализации нашей среды, и мне было интересно, как лучше всего разделить диск.
Для начала я буду использовать DC, базу данных SQL, SQL-репортаж, Exchange и веб-сервер, в конечном итоге пытаясь переместить оставшуюся часть нашей среды в эту настройку. Я ограничен в бюджете или хотел бы получить дополнительный MD1220. Достаточно ли здесь диска? Любые предложения о том, как мне это настроить?
Я бы поместил все 24 диска в одну и ту же группу дисков, чтобы получить максимально возможные накладные расходы ввода-вывода. В этом массиве вы будете размещать некоторые приложения с очень интенсивным вводом-выводом (SQL DB, SQL Reporting и Exchange), поэтому вам понадобится все, что вы можете получить. И, пожалуйста, не используйте приводы со скоростью вращения 7.2K об / мин; они могут быть дешевыми и большими, но вы заплатите за это масштабированием производительности.
На мой взгляд, такие оптимизации, как размещение трафика БД и журнала на разных шпинделях, скорее всего, будут заглушены общим трафиком ввода-вывода виртуализации. У вас будет два больших приложения ввода-вывода базы данных в этом хранилище (SQL и Exchange) и (опять же, на мой взгляд) вам понадобится столько накладных расходов на ввод-вывод, сколько вы можете получить, так что объедините все это в одно большое бассейн; жесткое разделение БД и ввода-вывода журнала приведет к тому, что вы быстрее столкнетесь с узкими местами.
Также подумайте о том, чтобы убедиться, что онлайн-дефрагментация и резервное копирование ваших серверов Exchange не совпадают с вашими резервными копиями SQL. Эти три операции представляют собой очень тяжелые операции ввода-вывода, и вы не хотите, чтобы они перекрывались, если это вообще возможно. Что касается служб Reporting Services, если у вас выполняются действительно большие запросы / отчеты / задания, старайтесь избегать периодов резервного копирования.
DC и веб-серверы здесь очень второстепенные, так что все должно быть в порядке.
ПОЧЕМУ вы должны объединять их все в одну группу, а не разделять их?
С 12 дисками 15 КБ и 12 дисками 10 КБ вам, вероятно, придется иметь две группы дисков, по одной для каждой скорости. Я бы не рекомендовал делиться дальше
12 дисков 15K должны обеспечить около 2270 операций ввода-вывода в секунду для полностью случайных операций ввода-вывода в R0, 1135–2270 для R10 и 2080 для R5. Диски 12x 10K должны дать вам 1700 операций ввода-вывода / с (850-1700 в R10, 1560 в R5). Скорости R10 являются переменными, потому что это зависит от ваших процентов чтения / записи, а также от того, будет ли контроллер обеспечивать чтение из нескольких полос (я не знаю, делает это Dell или нет). Значительно последовательные операции будут выполняться быстрее, но вы не можете рассчитывать на это с общей системой хранения.
Это неплохие скорости, но они также представляют максимальную производительность для каждого типа диска. Использование модели полного разделения для каждой из пяти выявленных вами услуг:
Я бы поместил последние два в пару 300 ГБ 10K дисков в конфигурации R1, оставив остальные 22 диска для остальных. В остальном ...
В зависимости от требований к емкости вам может потребоваться поменять местами тома БД / Журнала. Такая конфигурация дает для SQL и Exchange 945 операций ввода-вывода в секунду для журналов и почтовых хранилищ соответственно и 420 операций ввода-вывода в секунду для баз данных и журналов соответственно. Отчетность получает 280 операций ввода-вывода / с. Это дает общую производительность дисковой подсистемы 3230 операций ввода-вывода / с.
Сравните это с 3640 для общей производительности системы всего с двумя группами дисков. Это 12% производительности, которой вы жертвуете, чтобы изолировать свои производственные системы. Одно из главных преимуществ подобных систем общего хранения заключается в том, что вы можете более эффективно использовать хранилище. Разделение вещей, подобных вышеизложенному, означает, что вашим основным преимуществом является экономия затрат на размещение всего хранилища в одном устройстве на одном наборе контроллеров RAID вместо наличия нескольких контроллеров RAID.
Используя разрозненную конфигурацию выше, вы столкнетесь с узкими местами ввода-вывода Быстрее:
Когда другие говорят, что «одна большая группа дисков означает, что вы быстрее сталкиваетесь с узкими местами ввода-вывода», они обычно имеют в виду, что одно приложение с плохим поведением может повлиять на производительность в целом, и лучше всего разобщить все, чтобы защитить все от всего остального. Они относятся к хранилищу как к старым операционным системам, используемым для работы с памятью: каждый получает дискретное распределение памяти при запуске, и никто не может выйти за его пределы. В отличие от памяти, в этой модели нет такой вещи, как виртуальная память, поэтому во время запуска процессам назначается физическая память.
Лучше относиться к этому так же, как современные ОС относятся к памяти: виртуально. В системе доступно 3640 операций ввода-вывода, почему бы не позволить всем думать, что у нее есть столько возможностей для игры. Все не будут использовать это все время, и подсистема хранения сможет нормально обслуживать большинство запросов. Если спрос действительно достигает этого уровня, то все начинает тормозить (IOWAIT растет), и пора проанализировать систему, чтобы выяснить, что вызывает замедление.
Ну, я не эксперт, но для моей среды ESXi, в которой работает небольшой DC, небольшая база данных SQL и сервер Exchange. Мы просто слили все хранилище в один пул.
Основываясь на том, что я читаю, я думаю, что больше о том, как вы хотите выделить пространство, будет оставлено на этих отдельных виртуальных машинах, а не на серверной части хранилища.
Если вы используете VMware, я бы демонстративно использовал тонкое выделение ресурсов на дисках виртуальных машин, чтобы они не занимали все пространство, пока оно им не понадобится. Это сэкономило нам много места по сравнению с полным резервированием всего.