San Performance - Количество подключенных серверов

В производительности SAN задействовано так много переменных, что я могу понять, почему люди не слишком много в них участвуют.

Любая данная сеть SAN имеет основные компоненты, которые способствуют ее ограничениям;

• Контроллер / контроллеры - это / они принимают и обрабатывают запросы, поэтому здесь важны как их общие вычислительные возможности, так и возможности ввода-вывода - нет смысла иметь много быстрых дисков и / или несколько интерфейсов 8/10 Гбит / с, если контроллеры не могут идти в ногу. Сами контроллеры могут быть ограничены дизайном, возрастом компонентов, кэшем / с и, конечно, программным обеспечением, которое они запускают.
• Диски - очевидно, что диски FC 288 x 15krpm будут быстрее, чем 4 SATA-диска по 2 ТБ, - но вы обычно покупаете диски SAN по двум причинам, просто чтобы дать вам емкость, а иногда и для повышения производительности - конечно, если вы заинтересованы в производительность, то вы должны принять во внимание все остальное тоже.
• Интерфейсы ввода-вывода - опять же, как правило, нет смысла иметь много интерфейсов 8/10 Гбит / с, если контроллеры или диски не справляются.

Мне повезло, мне часто удается создать SAN-массивы для одной цели - либо адской работы для работы с БД, либо большого объема для видеоконтента или обратно - у меня есть роскошь получать отдельные системы для каждой функции, но время от времени мне нужно построить что-то, что охватывает немного и того и другого, вот что я делаю;

• Я выделяю самые быстрые доступные порты ввода-вывода для систем / подплатформ, которым нужна производительность - таким образом, эти машины (обычно, по моему опыту, БД) получают полную пропускную способность выделенных портов, и другие серверы, нуждающиеся в меньшей потребности, не имеют такой возможности, как эти по всей доступной пропускной способности. Я также покупаю выделенные высокопроизводительные (то есть SSD и / или 15k FC) диски и загружаю их в нужное количество полок, необходимое для оптимальной производительности для конкретной сети SAN (то есть блоков по 8 полок с коробками HP EVA и т. Д.). Если массив SAN способен к жесткому разбиению, я также выделю раздел (и часть кеша) для этой функции.
• Затем я выделяю значительную часть оставшихся портов ввода-вывода системам массового производства. Таким образом, их можно объединять вместе, им не мешают высокопроизводительные или низкоэффективные системы, и я покупаю достаточно быстро (обычно 10 кОм / мин). /SAS) диск, я могу выбрать для запуска их в выделенном разделе в зависимости от требований.
• Затем я оставил все остальные вспомогательные / тестовые / справочные / резервные и т. Д. Серверы на оставшейся паре портов, зная, что они на самом деле не заботятся о производительности и вряд ли насытят порты. Затем я могу с радостью назначить им медленные (7,2 об / мин SATA/FATA) диски (иногда мне приходится специально покупать диски с коэффициентом заполнения>30%).

Если вы спланируете свои системы таким образом, вы увидите постепенное, а не крутое, предсказуемое снижение производительности при добавлении серверов и загрузке. Очевидно, что вы не упоминаете какие-либо подробности вашего массива или схемы использования, но есть ситуации, когда один сервер может насытить DS3400/NetApp, и есть ситуации, когда буквально тысячи серверов покидают один и тот же ящик с оставленными океанами емкости - это действительно действительно сводится к проектированию системы и пониманию ваших моделей использования.

Не стесняйтесь возвращаться к нам, когда у вас есть больше данных.

НЕ зависит от количества систем, но от того, что они делают. SQL + exchange - активные пользователи. В частности, SQL может использовать МНОГО дисков для правильной работы (как и для любой базы данных), но опять же полностью в зависимости от того, что вы делаете. Однажды я видел SQL Server с 190 выделенными дисками. Мой собственный сейчас на 6 дисках, скоро обновляется.

Я не думаю - кроме технических ограничений - здесь возможно общее руководство.