Прожектор на СМБ-хранилище

Хранилище — крепкий орешек. Для бизнеса оно сложно тем, что нередко требует больших бюджетов за то, что кажется туманными преимуществами. Большинство руководителей понимают необходимость «хранить» данные и всё больше данных, однако мало что знают о производительности, методах доступа, избыточности и расчёте рисков, резервном копировании и аварийном восстановлении. Это делает работу ИТ сложной, поскольку нам нужно объяснять, почему бюджеты нередко должны быть очень большими на то, что кажется бизнес-стейкхолдерам невидимой системой.

Для ИТ хранилище сложно потому, что системы хранения данных комплексны — нередко это наиболее сложная система в рамках СМБ — и, из-за дороговизны и централизованности, существуют в очень небольшом количестве внутри компании. Это означает, что большинство СМБ, если у них вообще есть системы хранения данных, имеют лишь одну и эксплуатируют её очень долго. Отсутствие широкого опыта работы с системами хранения в совокупности с относительно редкой необходимостью взаимодействовать с ними оставляет ИТ-отделы СМБ наедине с крупной бюджетной статьёй, критически важной для бизнеса, которая занимает небольшой процент их «задач» и в отношении которой у них, по самой природе вещей, весьма мало реального опыта. Другие области ИТ значительно более доступны для экспериментов, тестирования и обучения.

На фоне этих двух главных вызовов мы имеем продукт, который в целом плохо понимается как руководством, так и ИТ. Хранилище настолько плохо понято, что ИТ-отделы нередко даже не знают, что им нужно, и фактически просто кидают дротики в дартс-мишень хранилища, начиная оттуда, куда они попали, — причём часто начиная с обращения к производителям, а не к консультантам, что уводит их по пути «решение уже принято», хотя формально они как будто получают совет.

Производители систем хранения, зная всё это, мало помогают изменить ситуацию: как только между СМБ и производителем устанавливается контакт, в интересах производителя — не обучать клиента, поскольку клиент уже принял решение обратиться именно к этому производителю, ещё не располагая необходимой информацией. Поэтому производитель просто хочет продать то, что у него есть. Редко у одного производителя систем хранения имеется широкая линейка продуктов, поэтому обращение к нему напрямую до понимания точных потребностей может в гораздо большей степени, чем в других сферах технологий, привести к тому, что клиент фактически уже определился с покупкой, — а это может привести к расходам, отличающимся от реальных потребностей на порядки.

Пример: большинство производителей серверов предлагают широкий ассортимент серверов — как в семействе x64, так и крупные RISC-машины и другие нишевые продукты. Большинство производителей систем хранения предлагают небольшое подмножество продуктов хранения, специализируясь только на SAN, или только на NAS, или только на хранилищах «мейнфреймового» класса, или только на небольших нереплицируемых системах хранения и т. д. Лишь очень немногие производители имеют широкий ассортимент продуктов хранения для удовлетворения большинства потребностей, и даже лучшие из них не охватывают полный рыночный спектр — от небольшого СМБ-рынка до среднего и корпоративного сегментов.

Итак, что делать дальше? Очевидно, это серьёзная задача.

Очевидный вариант, который компании не должны сбрасывать со счетов, — обратиться к консультанту по хранилищам. К кому-то, кто не перепродаёт одно решение или, как минимум, не ограничен одним решением, а располагает полным набором решений на выбор и способен предложить как дешёвое решение за 1000 долларов, так и решение за 1 000 000 долларов; к тому, кто понимает NAS, SAN, масштабируемые системы хранения, репликацию, переключение при отказе и т. д. Обращаясь к консультанту, не исходите из предположения, что знаете, каковы будут затраты, — факторов очень много, и, тщательно их рассмотрев, вы, возможно, потратите значительно меньше, чем ожидали. Однако имейте в виду бюджеты, чётко задокументируйте устойчивость к рискам, стоимость простоя и максимально полный набор ожидаемых сценариев использования хранилища.

Но обращение к консультанту — далеко не единственный путь. Самостоятельное исследование, изучение основ и следование структурированному процессу принятия решений могут привести вас, если не к правильному решению, то как минимум продвинуть по верному пути. Есть четыре основных фактора при выборе хранилища: функция (как хранилище используется и к нему осуществляется доступ), ёмкость, скорость и надёжность.

Первый фактор — функция — наиболее недооцениваемый и наименее понятный. На самом деле, даже несмотря на то что это наиболее базовая из всех задач, её часто просто замалчивают и забывают. Ответить на этот вопрос можно, задав себе вопрос: «Зачем мы приобретаем хранилище?»

Рассмотрим это систематически. Есть много причин для покупки хранилища. Вот несколько распространённых: снижение затрат по сравнению с хранением больших объёмов данных локально на отдельных серверах или рабочих станциях; централизация управления данными; повышение производительности; обеспечение доступности данных в случае сбоя системы.

Важно знать, какой из этих факторов — или какой иной фактор, не перечисленный здесь, — подталкивает вас к общему хранилищу, поскольку это, скорее всего, станет отправной точкой в процессе принятия решений. Пока мы не знаем, зачем нам нужно общее хранилище, мы не сможем определить его функцию, которая, как мы уже знаем, является наиболее фундаментальным фактором принятия решений. Если вы не можете определить функцию хранилища, можно с уверенностью предположить, что общее хранилище вам вовсе не нужно. Не бойтесь принять такое решение — подавляющему большинству малых предприятий общее хранилище практически не нужно или не нужно вовсе.

Определив функцию нашего общего хранилища, мы можем теперь относительно легко определить потребности в ёмкости и производительности. Ёмкость — это наиболее простая и очевидная функция хранилища. Производительность, или скорость, легко сформулировать и объяснить, однако значительно сложнее измерить количественно, поскольку IOPS — в лучшем случае туманная концепция, а в худшем — полностью непонятая. IOPS существуют в разных разновидностях, и здесь есть вопросы произвольного доступа, последовательного доступа, пиковых скоростей, задержки и устойчивых скоростей — плюс различия между чтением и записью! Сложно даже определить необходимую производительность, не говоря уже об ожидаемой производительности устройства. Но при тщательном исследовании это достижимо и измеримо.

Последний фактор — надёжность. Как и функциональность, она, по всей видимости, является постоянным камнем преткновения для ИТ-специалистов, рассматривающих переход на общее хранилище. Крайне важно — нет, абсолютно критично — помнить, что хранилище — это «просто ещё один сервер», и концепции избыточности и надёжности, применимые к обычным серверам, применимы в равной мере к выделенным системам общего хранилища. Почти во всех случаях корпоративные системы хранения строятся на корпоративных серверах — те же шасси, те же диски, те же компоненты. Нередко вводит в заблуждение то, что даже СМБ обращаются к средним или высококлассным системам хранения для поддержки серверов более низкого класса, что иногда делает системы хранения столь же загадочными, какими могут казаться крупные серверы тому, кто привык только к товарному серверному оборудованию. Но не заблуждайтесь: те же принципы надёжности применимы, и вам нужно будет оценивать риски точно так же, как вы всегда делали (или должны были делать), чтобы определить, какое оборудование вам подходит.

Время, потраченное на оценку, исследование и понимание потребностей в хранилище, очень важно, поскольку ваша система хранения, вероятно, останется базовым компонентом вашей сети очень долгое время из-за чрезвычайно высокой стоимости и сложности её замены. В отличие от последней версии Microsoft Office, покупка новой системы общего хранилища не окажет прямого влияния на рабочий стол руководителя и поэтому лишена той привлекательности, которая движет «обновлениями функций».

Теперь, когда перед нами стоят варианты, мы можем начать рассматривать конкретные продукты. На основе исследования функциональности мы теперь должны уметь определить, нужен ли нам SAN, NAS или ни то, ни другое. Во многих случаях — значительно чаще, чем люди думают, — ни то, ни другое является правильным ответом. Нередко добавление дисков к существующим серверам или подключение шасси прямого подключения (DAS) там, где это необходимо, оказывается более экономичным и надёжным, чем что-то более сложное. Это нельзя упускать из виду. На самом деле, если DAS удовлетворяет текущей потребности, редко когда что-то другое имело бы смысл. Простота — друг ИТ-менеджера.

Бывают случаи, когда DAS не удовлетворяет текущей потребности. Общее хранилище определённо имеет своё место, хотя бы для совместного использования файлов между настольными пользователями. С современными системами виртуализации общее хранилище становится всё более популярным, хотя даже там от DAS слишком часто отказываются, даже когда оно вполне могло бы удовлетворить существующим потребностям.

За редким исключением, когда нужно общее хранилище, следует обратиться к NAS. NAS расшифровывается как Network Attached Storage (сетевое хранилище данных). NAS имитирует поведение файлового сервера (NAS — это просто файловый сервер в упаковке устройства), что делает его простым в управлении и понимании. NAS, как правило, многофункционален — заменяет традиционные файловые серверы и нередко используется в качестве общего бэкенда для виртуализации. NAS характеризуется протоколами NFS и CIFS, но нередко на NAS-устройствах доступны также HTTP, FTP, SFTP, AFS и другие. NAS хорошо работает в качестве связующего звена, позволяя системам Windows и UNIX легко обмениваться файлами, работая каждая со своими собственными протоколами. NAS широко применяется в качестве общего хранилища для VMware vSphere, Citrix XenServer, Xen и KVM. С NAS легко использовать общее хранилище в различных ролях и обеспечивать хорошую утилизацию системы общего хранилища.

NAS не всегда удовлетворяет нашим потребностям. Некоторые специальные приложения по-прежнему нуждаются в общем хранилище, но не могут использовать протоколы NAS. Наиболее заметные продукты, попадающие в эту категорию, — Microsoft HyperV, базы данных и серверные кластеры. Для этих продуктов ответом является SAN. SAN, или Storage Area Networking (сеть хранения данных), — сложная концепция, которую даже в лучшем случае трудно однозначно классифицировать. Как NAS — это просто иной способ представления традиционных файловых серверов, так SAN — поистине просто иной способ представления дисков с прямым подключением. Хотя различия между SAN и DAS могут казаться очевидными, на практике провести между ними чёткую границу — в лучшем случае задача туманная, а в худшем — невозможная. SAN и DAS обычно разделяют протоколы, шасси, ограничения и носители. Многие SAN-устройства можно подключить и использовать как DAS. И большинство DAS-устройств можно подключить к коммутатору и использовать как SAN. На самом деле мы обычно используем эти термины для обозначения сценария их использования, а не чего-либо ещё.

SAN сложно использовать эффективно по многим причинам. Первая — плохое понимание. SAN на самом деле прост — настолько прост, что его очень сложно осмыслить, отчего он удивительно сложен на практике. SAN — это фактически просто DAS, который абстрагируется, переразбивается на разделы и снова представляется хостам как DAS. Термин «общее хранилище» вводит в заблуждение, поскольку, хотя технология SAN, как и NAS, позволяет нескольким хостам подключаться к единой системе хранения, она не обеспечивает какого-либо посредничества для хостов, подключённых к одной и той же файловой системе. NAS является интеллектуальным и обрабатывает это, упрощая «совместное использование» общего хранилища. SAN — нет, он слишком прост. SAN настолько прост, что по сути происходит следующее: один жёсткий диск (пусть и абстрагированный) подключается к контроллерам на нескольких хостах. В те времена, когда общее хранилище означало подключение двух серверов к одному кабелю SCSI, это было легко представить. Сегодня, с абстракциями SAN и широким распространением NAS, большинство ИТ-отделов забывают о том, что делает SAN, — и это может привести к катастрофе.

SAN, безусловно, занимает своё место, но SAN сложен в использовании и администрировании и очень ограничен. Нередко он также очень дорог. Практическое правило для SAN таково: если вам не нужен SAN — используйте что-то другое. Всё просто. Следует избегать SAN до тех пор, пока он не окажется единственным вариантом, и тогда он является правильным выбором. Его редко выбирают из соображений производительности или стоимости, поскольку обычно он уступает другим вариантам по обоим параметрам. Но когда вы строите бэкенд для HyperV или создаёте кластер баз данных, у вас не будет другого варианта. Для большинства сценариев использования в СМБ эффективное использование SAN потребует размещения NAS перед ним для совместного использования хранилища.

NAS составляет подавляющее большинство сценариев использования общего хранилища. Он прост, хорошо понятен и гибок.

Многие, если не большинство, современных устройств общего хранилища поддерживают как SAN, так и NAS, и различие между ними — в использовании, протоколах и идеологии, а не в чём-либо другом. Нередко физические устройства схожи, если не одинаковы, как и технологии подключения сегодня.

Прежде всего важно иметь конкретные цели при поиске общего хранилища. Запишите эти цели и рассмотрите каждую технологию и продукт с точки зрения того, как и в какой мере они соответствуют этим целям. Не принимайте поспешных решений и не руководствуйтесь маркетинговыми материалами или тем, что кажется рыночным трендом. Начните с того, чтобы определить, нужно ли вообще общее хранилище. Если да — определите, отвечает ли NAS вашим потребностям. Если нет — рассмотрите SAN. Хранилище — это огромная инвестиция: потратьте время на изучение альтернатив, проведите тщательное исследование, и только сузив выбор до нескольких конкретных конкурентных продуктов — обращайтесь к производителям за окончательными деталями и ценами.