Успешное развитие бизнеса сопровождается радикальным увеличением объема корпоративных данных, и в какой-то момент модернизация инфраструктуры хранения становится неизбежной. Развертывание сети хранения позволяет решить эту задачу наиболее гибким способом.
За последние 20 лет парадигма инфраструктуры ИТ претерпела радикальные изменения — теперь основную ценность составляют не вычислительные мощности и сетевые ресурсы, а данные. Руководители департаментов ИТ постепенно приходят к осознанию того факта, что подсистема хранения — самый ценный объект инфраструктуры, реализация которого требует тщательной проработки вопросов размещения, внедрения и обслуживания.
Рынок систем хранения в России несколько запоздал со стартом, но зато может дать фору западному рынку по темпам внедрения сетей хранения (Storage Area Network, SAN), ибо с энтузиазмом воспринял эту передовую технологию. Столь интенсивному распространению SAN способствуют темпы роста экономики страны в целом и отрасли ИТ в частности, а также усилия участников рынка по продвижению современных решений.
САМ СЕБЕ РЕЖИССЕР
Проект по внедрению сети хранения в московском офисе компании OCS отличается тем, что его заказчик, исполнитель и поставщик оборудования един в трех лицах. Компания работает на рынке с 1994 г. и интенсивно развивается — в настоящее время помимо головного офиса в Санкт-Петербурге у нее имеется крупный филиал в Москве, а также региональные филиалы в Перми, Екатеринбурге, Челябинске, Новосибирске, Ростове-на-Дону, Воронеже, Нижнем Новгороде и Самаре. За последние два года бизнес компании значительно вырос. Так, за 2003 г. объем продаж увеличился на 60% и составил 236 млн долларов, а число партнеров достигло 2400.
О перспективе модернизации системы хранения данных руководство подразделения ИТ московского офиса OCS задумалось два года назад, когда объем данных, которыми приходится оперировать различным подразделениям, еще не требовал принятия срочных мер, но темпы роста вызывали серьезное опасение. Реальность, как это часто бывает, превзошла ожидания. Постоянное увеличение числа заказчиков и партнеров, а также последовавшее за ним расширение штата компании с неизбежностью вело к росту запросов через серверы к данным со стороны клиентов. Все это предвещало замедление работы критически важных приложений и невозможность выполнения в положенный срок процедуры ежедневного резервного копирования из-за ее продолжительности.
По мере развития бизнеса появилась настоятельная потребность привести инфраструктуру в соответствие бизнес-процессам, дабы обеспечить своевременный и надежный доступ к нужной информации и ее извлечение из общего массива данных. Несмотря на всю важность стоящих задач, на подобный проект, как правило, выделяется ограниченный бюджет, в результате возникает необходимость оптимизировать стоимость и самого решения, и, что еще более важно, эксплуатации внедряемой системы.
Московскому офису OCS приходится иметь дело с типичными для дистрибьютора задачами управления продажами, заказами и поставками, а также поддержки складского учета и аналитических функций, которые решает прикладная система OLAP. При этом требуется обеспечить высокую производительность как для транзакций, оперирующих небольшими блоками данных, так и для выполнения параллельных OLAP-запросов в реальном времени. При использовании прежней инфраструктуры хранения две подобные задачи зачастую оказывались взаимоисключающими, но сеть хранения позволяла устранить этот конфликт за счет наращивания мощности системы по мере необходимости на том участке, где это требуется в конкретный момент времени.
Кроме того, в компании накоплен огромный опыт предпродажного консалтинга, который зафиксирован в большом количестве архивных документов. Эти знания бесценны при подготовке и реализации новых проектов, а также при модернизации инфраструктуры заказчиков. По каждому из проектов бережно хранится не только проектная документация (спецификации, структурные схемы, сопроводительные записки), но и вся деловая переписка. Обычно из всего объема архивных данных требуется оперативно отыскать и восстановить лишь их небольшую часть. Для упорядочивания хранения и доступа к информации был нужен особый подход, позволяющий выделить критичные с точки зрения бизнеса данные, четко контролировать целевые характеристики системы и управлять ими по возможности просто и прозрачно.
ОТ ЧАСТНОГО К ОБЩЕМУ
Среди множества приложений, используемых в московском офисе OCS, наиболее жесткие требования к высокой доступности предъявляют прежде всего система ERP с собственной базой данных и корпоративная почтовая система Microsoft Exchange, без которых представить работу офиса уже немыслимо. Кроме того, пользователям приходится иметь дело с большим количеством рабочих файлов, которые до внедрения сети хранения размещались на внутренних дисках серверов.
К моменту начала проекта система резервного копирования нуждалась в безотлагательной модернизации из-за больших объемов данных в каждой из подсистем. Процедура резервного копирования, во время которой приходилось приостанавливать функционирование приложений, перестала укладываться в ночную паузу между 10 ч вечера и 9 ч утра. Установка же для каждого сервера дорогостоящего ленточного накопителя представлялась не только дорогостоящим решением, но и привела бы к неуправляемой ситуации: даже в случае одного такого накопителя регулярная проверка лент и их замена — занятие весьма хлопотное.
К началу реализации проекта время поиска данных стало недопустимо большим, и работа бизнес-приложений стала замедляться. Так, если раньше почтовый сервер не предъявлял высоких требований к объему дискового подпространства, то к моменту модернизации постоянно возникали проблемы из-за отсутствия места на дисках почтового сервера и сервера для рабочих файлов пользователей. Между тем на сервере с системой ERP заполнение дисковой подсистемы происходило гораздо медленнее, однако даже при наличии свободных дисков другие приложения не могли их использовать.
В качестве одного из возможных решений на этапе планирования модернизации инфраструктуры обсуждалось подключение кластера из двух серверов к общему внешнему хранилищу на базе JBOD — кабинету с дисками и контроллером с небольшим объемом памяти. Однако анализ эффективности показал, что такое решение, с одной стороны, слишком дорого, а с другой — решает лишь часть задач и не имеет перспектив с точки зрения масштабирования в будущем. К тому же подобная архитектура не обеспечивала бы необходимый уровень отказоустойчивости, поскольку массив JBOD не обладает интеллектуальной функциональностью и не предусматривает балансировку нагрузки, из-за чего производительность основного и вспомогательного сервера использовалась бы неэффективно. Данная конфигурация не поддерживала бы единого унифицированного дискового пространства, и различные серверы (баз данных, системы ERP, почтовый) не могли бы совместно размещать данные на внутренних дисках JBOD. Из-за того, что серверы работают в разных операционных средах, реализовать принцип блочной передачи данных не представлялось возможным, поскольку операционные системы базируются на различных форматах файлов. Кроме того, модернизацию самого дискового массива путем увеличения количества дисков внутри кабинета проводить было также нецелесообразно. Свободного пространства в кабинете не так много, да и приобретение идентичных дисков с течением времени превратилось бы в проблему поиска музейных редкостей, поскольку технология их изготовления меняется очень быстро. Такой подход не устранял основные проблемы, а обеспечивал лишь кратковременное решение.
Какие же требования предъявлялись к новой подсистеме хранения? Одна из главных задач — упрощение процедуры управления данными, чего можно было достичь при условии замены разрозненных подсистем на единое хранилище. Для этого следовало осуществить консолидацию дискового пространства, что позволило бы устранить прогрессирующий дисбаланс в утилизации дискового пространства серверами и оптимизировать нагрузку на серверы с использованием средств интеллектуальной балансировки запросов. Не менее важное значение имело сокращение размера окна ежедневного резервного копирования и обеспечение возможности его проведения в любой момент времени без остановки приложений.
Анализ перечисленных требований показал, что оптимальным решением является сеть хранения. Ее внедрение позволяло устранить потенциальные источники общего отказа на каждом из логических уровней — от дискового пространства до бизнес-приложений. Высокая скорость работы с СУБД, почтовым хранилищем и пользовательскими папками в режиме реального времени также наилучшим образом обеспечивалась на уровне сети хранения.
Кроме того, в последнее время появились эффективно интегрируемые в SAN инструменты для тонкой настройки Microsoft SQL Server, детального резервного копирования для почтовых систем, например Microsoft Exchange, и извлечения информации вплоть до отдельного сообщения. Одно из подобных решений — Solution E-Mail, включающее в себя комплексные программные и аппаратные средства и предназначенное для снижения стоимости и повышения надежности систем электронной почты, — предложила компания EMC.
КРАСНАЯ СТРЕЛА
В качестве основы построения SAN была выбрана система хранения данных EMC CLARiON CX300, подключение которой к серверам корпоративной сети осуществлялось посредством коммутаторов Cisco MDS 9140 на 40 портов с фиксированной конфигурацией и MDS 9216 на 16 портов с модульной конфигурацией на базе интерфейсов SFP (см. Рисунок 1).
|
| Рисунок 1. Корпоративная сеть хранения московского офиса OCS. |
Одно из наиболее существенных соображений при выборе системы хранения CLARiON состояло в возможности ее модернизации до более производительной системы CX700 посредством замены контроллеров и добавления полок с дисками. К тому же эта система спроектирована в соответствии с принципами обеспечения отказоустойчивости, все ее компоненты (контроллеры, входные порты, блоки питания и т. д.) дублируются, а уровень RAID обеспечивает защиту внутреннего дискового пространства. Установка резервного коммутатора позволяет реализовать резервный путь от серверов к системе хранения, при этом переключение путей и балансировку нагрузки выполняет ПО EMC Power Path.
Общая надежность сети хранения в значительной степени зависит от разграничения прав доступа. Благодаря настройке функциональности Role Based Access Control (списки доступа к интерфейсу управления в соответствии с ролью пользователя) коммутаторы сети хранения Cisco MDS 9140 и MDS 9216 позволяют назначать десятки различных ролей для разного уровня администраторов, специалистов и пользователей. Кроме того, с их помощью можно анализировать конфигурацию других компонентов сети вплоть до версии программного обеспечения адаптеров шины хоста, конфигурировать журналы событий на портах различных устройств и активно с ними взаимодействовать. На уровне коммутатора можно проводить сбор и анализ пакетов, а результаты потом просматривать через интерфейс Web. При необходимости к коммутатору подключают внешний анализатор блоков данных Fibre Channel для анализа всех пакетов.
Оба установленных коммутатора поддерживают соединение через интерфейс Fibre Channel, причем модель MDS 9216 содержит модуль расширения для одновременного обеспечения сервисов iSCSI либо FC-IP. Протокол iSCSI эффективно решает задачу подключения рабочих станций и в особенности модульных серверов к системам хранения Fibre Channel, поскольку устанавливать отдельный адаптер шины хоста (HBA) в каждый модульный сервер слишком дорого, а протокол iSCSI позволяет в рамках имеющейся локальной сети на базе стека TCP/IP более гибко, надежно и недорого удовлетворить запросы серверов, для которых в данное время не требуется максимальной производительности при работе с хранилищами данных. Как пояснил Руслан Чиняков, технический директор московского офиса компании OCS, iSCSI привлекает возможностью универсального доступа на блочном уровне, благодаря чему эту технологию можно использовать для решения любых задач. В то же время более традиционные решения NAS имеют массу ограничений, так как воплощают идею доступа на уровне файловой системы, поэтому их применение в ряде приложений может быть проблематично.
Поддержка в том же универсальном модуле протокола FC-IP позволяет связать удаленные «острова» сети хранения Fibre Channel. Протокол FC-IP предлагает универсальное средство для связи удаленных офисов компании при построении отказоустойчивых географически распределенных центров обработки данных. Поскольку даже в крупных российских городах «темное» оптическое волокно еще далеко не всегда доступно, а строительство сетей DWDM/ CDWM только-только начинается, большинство распределенных систем в качестве транспортной среды оснащается низко- и среднескоростными сегментами на базе стека TCP/IP.
В транспортном сегменте гарантии качества сервиса при перемещении инкапсулированных пакетов (удержание задержки в заданных границах, исключение потерь пакетов и приоритезация инкапсулированных пакетов) реализуются с помощью маршрутизаторов и коммутаторов общего назначения. FC-IP обеспечивает взаимодействие коммутаторов и маршрутизаторов хранения в прозрачном для хостов и целей режиме. Организация туннеля FC-IP между московским офисом компании и центром обработки данных OCS в Санкт-Петербурге — вопрос ближайшего будущего.
Со временем в сети хранения московского офиса OCS планируется установить еще один коммутатор MDS 9140, а MDS 9216 будет использоваться для обучения партнеров и отладки пилотных проектов. Планы на будущее связаны с организацией на базе имеющейся подсистемы хранения процедуры бессерверного копирования и восстановления данных.
Одно из важнейших требований к системе хранения касается обеспечения надежности и стабильности совместного доступа к ресурсам. Благодаря расширенной функциональности PowerPath, логические диски объединяются на уровне сервера в группы, а доступ к конечным устройствам осуществляется с помощью маскирования LUN. При отказе одного из коммутаторов либо одного из HBA на сервере данные останутся доступными для приложений, поскольку будет сразу же задействован второй резервный путь к логическим дискам массива.
С помощью оборудования Cisco серии MDS удалось не только обеспечить отказоустойчивость, но и добиться разделения на практически независимые подсистемы. Технология виртуализации сети хранения VSAN сохраняет возможность пользоваться ресурсами прозрачным образом даже при выходе из строя модуля или всего коммутатора. Изменение же нагрузки на портах коммутатора или в уровне функциональности, связанной с одной группой ресурсов, никак не сказывается на другой.
ВЫВОД
Общая концепция проекта была принята в июне, а в сентябре уже началась эксплуатация сети хранения. Большую часть времени заняла проработка проекта и проверка работоспособности сети хранения при отказе отдельных компонентов с моделированием внештатных ситуаций. Выполнение проекта никак не сказалось на привычном ритме функционирования корпоративной сети, поскольку все работы по подключению нового оборудования и отладке подсистемы хранения выполнялись в выходные дни. В настоящее время идет подготовка к включению в состав сети хранения серверов второй очереди.
Суммарный объем данных, которыми сейчас оперирует московский офис OCS, превышает 1 Тбайт. Сеть хранения позволила перенести данные, используемые основными приложениями, а также рабочие файлы всех пользователей в централизованное хранилище. Помимо преимуществ, достигнутых благодаря консолидации, в новой архитектуре хранения существенно упростилась процедура резервного копирования и восстановления, выполняемая одновременно для всех серверов.
В недалеком будущем компания намерена связать сеть хранения московского офиса с офисом в Санкт-Петербурге и впоследствии распространить этот опыт на другие филиалы. У многих партнеров и заказчиков OCS имеется настоятельная потребность в подобном решении, а реализованный проект должен стать убедительной демонстрацией его достоинств.
Наталья Жилкина — научный редактор «Журнала сетевых решений/LAN». С ней можно связаться по адресу: nzil@lanmag.ru.
Коротко о главном
Московский офис OCSЗаказчик и исполнитель: Московский офис OCS
121609, г. Москва, Осенний бульвар, д. 23, БЦ «Крылатский» http://www.ocs.ru
Факты. Дистрибьюторская компания OCS основана в марте 1994 г. В настоящее время она имеет центральный офис в Санкт-Петербурге и офис в Москве, склады и сервисные центры в этих городах, а также развитую региональную сеть филиалов, складов и сервисных служб в Перми, Екатеринбурге, Челябинске, Новосибирске, Ростове-на-Дону, Воронеже, Нижнем Новгороде и Самаре. В 2003 г. объем продаж вырос на 60%, а ее партнерская сеть насчитывала уже 2400 компаний. В том же году OCS вместе с Landata, «Aквариус» и «АНД Проджект» вошла в состав холдинга «Национальная компьютерная корпорация» (НКК).
Задача. Увеличение количества числа контрактов с вендорами и расширение партнерской сети повлекли за собой резкое увеличение объема данных — свыше 1 Тбайт — в московском офисе компании. В результате возникла настоятельная потребность в модернизации собственной инфраструктуры хранения корпоративных данных, которая бы наилучшим образом соответствовала целям бизнеса с учетом перспективного роста компании.
Решение. С июня по сентябрь в московском офисе компании полностью переоснастили инфраструктуру хранения корпоративной информации. Для этого была спроектирована и внедрена сеть хранения данных на основе двух коммутаторов Cisco и системы хранения EMC CLARiiON. Особенность проекта состоит в том, что весь цикл работ, включая поставку техники, проектирование и внедрение сети хранения, организацию резервного копирования и восстановления, процедуру архивирования данных, выполнили специалисты OCS — компания выступила в роли заказчика и исполнителя.
Вывод. Основные приложения, а также рабочие файлы всех пользователей удалось перенести в централизованное хранилище. Благодаря консолидации дискового пространства значительно упростилась процедура управления единой системой хранения, включая систему резервного копирования и восстановления данных, был устранен дисбаланс в утилизации дискового пространства между серверами и оптимизирована нагрузка на серверы с использованием средств интеллектуальной балансировки запросов. Это позволило повысить общую надежность сети хранения — в том числе за счет применения технологии виртуализации доступа к ресурсам. Кроме того, процедура резервного копирования может проводиться теперь в любой момент без остановки приложений.