Как способ совместного использования дисков по ту сторону серверов, SAN заслуживает более внимательного отношения.
Будучи относительно новой технологией, сеть хранения (Storage Area Network, SAN) с трудом поддается оценке с точки зрения практической целесообразности ее применения: "хранение" и "сети" обычно развиваются в соответствии с собственными тенденциями, а то, что проникает за водораздел между ними, часто искажается рекламной шумихой с обеих сторон.
Год назад я сравнил эту технологию с балансировкой нагрузки. С тех пор те же самые вопросы, вследствие которых балансировка нагрузки между серверами привлекла к себе внимание, породили вторую волну интереса к SAN. С ростом популярности Internet и технологий IP/Web для распространения внутрикорпоративной информации серверные фермы за последние два года значительно увеличились в размерах. Для поддержки растущего числа клиентов компании стали прибегать к различным способам распределения обработки транзакций между серверами. Балансировщики нагрузки могут помочь в повышении производительности транзакций, но они оказываются бессильны, если от серверов требуется обеспечить доступ и обновление общей базы данных. Здесь-то и пригодятся SAN.
Не все понимают, зачем надо использовать SAN вместо стандартной дисковой подсистемы или стандартной системы хранения. Ответ прост: сети хранения обеспечивают большому количеству серверов доступ ко множеству дисковых ресурсов по принципу "каждый с каждым" - своего рода способ разделения дисков позади сервера. Именно этим обосновывается внедрение SAN и традиционных сетевых клиент-серверных приложений или приложений обработки транзакций. Назовем три главные причины применения SAN: разделяемая приложениями база данных, "привлекательные" приложения и высокие требования к доступности.
В разделяемой между приложениями базе данных хранится общая информация для разных приложений. Когда ее используют распределенные между несколькими серверами приложения, она также должна быть распределенной, а это может привести к проблемам синхронизации.
С "привлекательными" приложениями возможны те же трудности. В большинстве компаний имеются "привлекательные", или ключевые, приложения, доступ к которым должны иметь большинство пользователей. Часто связанная с этими приложениями активность чрезмерна для одного сервера, но разделение приложения между несколькими пользователями ведет к "проблеме разделяемой базы данных".
Один сервер может справляться с предлагаемой нагрузкой, но не обеспечить устойчивость к аппаратным/программным сбоям. При использовании параллельно сервера для резервирования первичного базы данных на обоих должны быть синхронизированы, так что мы снова приходим к "проблеме разделяемой базы данных" - и к SAN.
Производители компьютеров предлагают альтернативы SAN в виде серверов со специальной архитектурой, часто называемых "c обработкой транзакций" или "c параллельной обработкой". Эти архитектуры интересны в первую очередь тогда, когда все серверы поставляются одним поставщиком. Остановить свой выбор на SAN лучше всего в том случае, если вы не хотите зависеть от одного поставщика и, возможно, от конкретной ОС. Это тот случай, когда для поддержки сетевых клиентов используются технологии на базе Web либо потому, что ваша компания занимается маркетингом или продажами через Internet, либо потому, что внутрикорпоративная сеть Intranet организована в соответствии с характерными для Internet принципами в виде Intranet. Ввиду простоты дублирования данных со статическим содержимым наибольшую выгоду применение SAN дает в случае динамического информационного наполнения - особенно когда оно постоянно меняется в течение дня.
На физическом уровне SAN во многом аналогична локальной сети. Большинство сетей хранения создается с использованием Fibre Channel или высокоскоростных соединений Ethernet (Gigabit Ethernet) и коммутаторов. Серверы подключаются посредством адаптеров/плат SAN, эмулирующих стандартный дисковый интерфейс (такой, как SCSI) с сервером. Но то, как они работают с конкретным набором дисков или серверов, может иметь свои отличия в зависимости от производителя. Если вы задумываетесь о внедрении SAN, то начать следует с вашего основного производителя серверов и поставщика OC. У большинства из них есть своя стратегия в области SAN, так что лучше всего придерживаться подхода, принятого вашим поставщиком. Другие устройства (оборудование сети SAN, устройства хранения и сетевые серверы) следует выбирать в соответствии с этой архитектурой.
При внедрении SAN вам предстоит рассмотреть во многом те же вопросы планирования ресурсов сети, что и в случае стандартных сетевых технологий. Сеть хранения не должна быть перегружена, так как это может отрицательно сказаться на функционировании приложений.
Если в качестве связующей архитектуры SAN предполагается использовать Ethernet, то устройства и каналы Ethernet не следует задействовать одновременно и в SAN, и в локальной/глобальной сети. Уровень трафика в сети хранения очень высок, что может отрицательно сказаться на работе в сети других приложений. Конкуренция между трафиком сети хранения и трафиком локальной/глобальной сети ведет к противопоставлению сетевого и дискового трафика и, таким образом, к проблемам согласования по времени, воспроизвести которые практически невозможно, как и осуществить последующую диагностику и исправление.
Применение Fibre Channel может оказаться ничем не лучше, несмотря на разнообразие имеющихся устройств хранения на его основе. Впрочем, накопленная практика инсталляции укрепляет доверие пользователей к этой технологии. Важнейшее значение имеют правильное проектирование сети хранения и сокращение влияющих на производительность переменных; традиционная диагностика проблем в сети не очень подходит для SAN, так что лучший выход - избегать их с самого начала.
SAN пока не удалось завоевать мир, но последние тенденции в области электронной коммерции привели к расширению использования сетей SAN различными компаниями. Может быть, и вам стоит присмотреться к SAN более внимательно.
Том Нолле - президент CIMI, консалтинговой компании в области стратегического технологического планирования. С ним можно связаться по адресу: tnolle@cimicorp.com.