Я пытаюсь разобраться в некоторой инфраструктуре SAN, и я надеялся, что некоторые из вас, обладающие большим опытом, чем я, могут помочь мне понять масштабирование с помощью SAN.
Представьте, что у вас есть компьютерные серверы с HBA. Они подключаются напрямую или через коммутатор к контроллеру SAN. Затем контроллер SAN предоставляет один или несколько LUN, которые, скорее всего, сопоставлены с массивом RAID на устройстве хранения.
Так что, если я правильно понимаю, «контроллер» представляет собой узкое место в производительности. Если вам нужна высокая производительность, вы добавляете дополнительные контроллеры с подключениями к их собственному хранилищу, которые затем сопоставляются с серверами, которым они нужны.
Я полагаю, вы можете получить очень высокопроизводительные контроллеры с огромной емкостью хранения и контроллеры с более низкой производительностью с более низкой максимальной производительностью? Но если у вас есть коммутатор, вы можете добавить в сеть несколько контроллеров с более низкой производительностью по мере необходимости?
Пожалуйста, разорвите мое понимание, если я ошибаюсь, но я пытаюсь понять, как вы подключаете HBA-адаптеры от сервера к хранилищу без структуры, просто представляющей «магию».
Контроллер как узкое место производительности вполне справедливо, и он также может представлять единственную точку отказа в некоторых архитектурах. Об этом известно довольно давно. Некоторое время существовали методы решения этой проблемы, специфичные для конкретных производителей, но с тех пор отрасль в целом сконцентрировалась на так называемом MPIO или многопутевом вводе-выводе.
С помощью MPIO вы можете представить один и тот же LUN на нескольких путях в структуре хранения. Если HBA сервера и HBA массива хранения имеют по два подключения к структуре хранения, у сервера может быть четыре отдельных пути к LUN. Он может выйти за рамки этого, если хранилище поддерживает это; в более крупных системах дисковых массивов довольно часто используются конфигурации с двумя контроллерами, при этом каждый контроллер представляет активное соединение с LUN. Добавьте сервер с двумя отдельными картами HBA и двумя физически отдельными путями, соединяющими пары контроллер / HBA, и вы получите путь к хранилищу без единой точки отказа.
Более причудливые контроллеры действительно будут полной парой «активный / активный», при этом оба контроллера фактически взаимодействуют с хранилищем (как правило, между контроллерами существует некоторая форма общего кеша для помощи в координации). Устройства среднего уровня могут притворяться активными / активными, но только одно устройство фактически выполняет работу в любой момент времени, но резервный контроллер может немедленно начать работу, если первое перешло в беззвучный режим и никакие операции ввода-вывода не были прерваны. Устройства нижнего уровня находятся в простом режиме «активный / резервный», где весь ввод / вывод выполняется по одному пути и перемещается по другим путям только тогда, когда активный путь умирает.
Наличие нескольких активных контроллеров действительно может обеспечить лучшую производительность, чем один активный контроллер. И да, добавьте достаточное количество систем, поражающих хранилище, и достаточно быстрое хранилище за контроллером, и вы действительно можете насыщать контроллеры настолько, чтобы все подключенные серверы это заметили. Хороший способ смоделировать это - вызвать необходимость перестроения тома RAID с контролем четности.
Не все системы могут использовать MPIO для использования нескольких активный пути, это все еще несколько ново. Кроме того, одна из проблем, которая должна быть решена всеми контроллерами, - это обеспечение того, чтобы все операции ввода-вывода выполнялись по порядку, несмотря на путь, по которому поступил ввод-вывод, и на любом контроллере, получившем операцию. Чем больше контроллеров вы добавляете, тем сложнее эта проблема. Ввод-вывод хранилища - это принципиально сериализованная операция, которая плохо работает с массивным параллелизмом.
Вы можете получить некоторый выигрыш, добавив контроллеры, но выигрыш быстро исчезает в свете дополнительной сложности, необходимой для того, чтобы заставить его вообще работать.
Проблема с попыткой объединить устройства с низкой производительностью заключается в характере доступа программного обеспечения к хранилищу. Типичная программа выдаст read запрос и семантика read операции требуют, чтобы операционная система предоставляла процессу результаты read. Операционная система, как правило, не имеет возможности узнать, что этому процессу или потоку потребуется дальше. Он может попытаться угадать с опережением чтения, но это не всегда верно.
Поэтому, если вы попытаетесь использовать множество посредственных контроллеров, вы получите большую задержку, потому что посредственным контроллерам требуется больше времени, чтобы получить свои запросы по сети и доставлять их по сети. Тот факт, что у вас простаивает куча других контроллеров, не дает вам намного большей скорости.
Здесь есть некоторая зависимость от приложения. Некоторые рабочие нагрузки выдают множество запросов из разных мест или используют API асинхронного чтения файлов, которые позволяют одному и тому же потоку выдавать несколько запросов, прежде чем ждать завершения любого из них. Некоторые приложения сильно выигрывают от опережения чтения, устраняя значительную задержку. Но если вам нужно универсальное решение, которое хорошо работает, вам нужны контроллеры с низкой задержкой, чтобы вам не пришлось ждать контроллер, прежде чем вы даже сможете выяснить, какие данные вам нужны дальше.