Производительность SAN включает в себя так много переменных, что я могу понять, почему люди не слишком вникают в них.
Любая конкретная сеть хранения данных имеет основные компоненты, которые способствуют ее ограничениям, а именно;
- Контроллер / ы - это / они принимают и обрабатывают запросы, поэтому их общие вычислительные возможности и возможности ввода-вывода являются здесь ключевыми - нет смысла иметь много быстрых дисков и / или несколько интерфейсов 8/10 Гбит / с, если контроллеры не могут справиться. Сами контроллеры могут иметь ограничения по дизайну, возрасту компонентов, кэш-памяти и, конечно же, программному обеспечению, которое они запускают.
- Диски - очевидно, что диски FC со скоростью 288 x 15 об / мин будут быстрее, чем диски SATA 4 x 2 ТБ, но вы обычно покупаете диски SAN по двум причинам: просто для увеличения емкости, а иногда и для повышения производительности - конечно, если вас интересует производительность, то вам нужно принять во внимание и все остальное.
- Интерфейсы ввода-вывода - опять же, обычно нет смысла иметь много интерфейсов 8/10 Гбит / с, если контроллеры или диски не успевают.
Мне повезло, мне часто удается создавать массивы SAN для одной цели - чертовски быстро для работы с БД или большой для видеоконтента или обратно - у меня есть роскошь получить отдельные системы для каждой функции, но время от времени мне нужно построить что-то, что покрывает оба аспекта, вот что я делаю;
- Я выделяю самые быстрые доступные порты ввода-вывода для систем / суб-платформ, которым нужна производительность - таким образом эти машины (обычно БД по моему опыту) получают полную пропускную способность выделенных портов, нет возможности для других серверов, нуждающихся в меньшей степени, чем эти, чтобы топтать по всей доступной полосе пропускания. Я также покупаю выделенные высокопроизводительные диски (например, SSD и / или 15k FC) и загружаю их на нужное количество полок, необходимое для оптимальной производительности для конкретной SAN (то есть блоки из 8 полок с блоками HP EVA и т. Д.). Если массив SAN допускает жесткое разбиение на разделы, я также выделю раздел (и часть кеша) для этой функции.
- Затем я выделяю значительную часть оставшихся портов ввода-вывода для основных производительных систем, таким образом, они могут быть объединены вместе, они не будут подвергаться перекрестным помехам со стороны высокопроизводительных или низкопроизводительных систем, и я покупаю достаточно быстро (обычно 10krpm FC / SAS), я могу запустить их в выделенном разделе в зависимости от требований.
- Затем я помещаю все другие вспомогательные / тестовые / справочные / резервные серверы на оставшуюся пару портов, зная, что они действительно не заботятся о производительности и вряд ли переполнят порты. Затем я могу с радостью назначить им медленные (7,2 об / мин SATA / FATA) диски (иногда мне также приходится покупать диски с рабочим циклом> 30%).
Если вы планируете свои системы таким образом, вы увидите постепенное, а не резкое, предсказуемое падение производительности по мере добавления серверов и нагрузки. Очевидно, что вы не упоминаете никаких подробностей о своем массиве или схеме использования, но бывают ситуации, когда один сервер может перегрузить DS3400 / NetApp, и бывают ситуации, когда буквально тысячи серверов покидают тот же ящик с океаном оставшейся емкости - это действительно сводится к проектированию системы и пониманию ваших шаблонов использования.
Не стесняйтесь возвращаться к нам, когда у вас будет больше данных.
НЕ зависит от количества систем, а от того, что они делают. SQL + exchange - активные пользователи. В частности, SQL может использовать МНОГО дисков для правильной работы (как и любая база данных), но опять же полностью в зависимости от того, что вы делаете. Я однажды видел SQL Server с 190 выделенными дисками. Мой сейчас на 6 дисках, скоро обновлю.
Я не думаю, что помимо технических ограничений, здесь возможны общие указания.