about NetApp

В хранении информации следует различать “резервное копирование” (backup) и “архивирование” (archiving).

Различие тут в целях. Если резервное копирование совершается для того, чтобы информацию восстановить, то есть конечным результатом бэкапа является восстановление (restore) информации на прежнем месте, то целью архивирования является создание долговременно хранимого экземпляра информации, без цели его возвращения на прежнее место хранения.
Часто архивирование осуществляется с удалением оригинала на оперативном хранилище (move), в отличие от бэкапа, когда оригинальная информация остается на своем прежнем месте (copy).

Кроме того, сама задача архивирования, как правило, требует длительного, упорядоченного хранения, сохранения “версий” и эффективного поиска среди сохраненной информации.
Часто “чистое” резервное копирование комбинируется в реальной жизни с архивированием, так, например, объектом архивирования могут служить сами резервные копии, если мы, например, храним наши резервные копии, не только последнюю, для целей немедленного восстановления состояния информации, но и состояние на день, два, неделю или месяц назад.

Несколько лет назад широкую популярность получила концепция ILM - Information Lifecycle Management - Управления жизненным циклом информации. Методы резервного копирования и архивации удачно легли в эту концепцию, и сейчас многие IT-проекты разрабатываются с использованием этой идеи.
Вкратце, ILM - это определение циклического движения информации, которая по мере своей жизни сперва создается, затем обрабатывается, хранится в оперативном доступе, затем переходит в архив, а затем передается на уничтожение в связи с окончанием срока жизни.

Одной из идей, легших в основу ILM была идея того, что информация, в зависимости от прохождения этапов своей жизни, имеет различные требования к оперативности (и стоимости) своего хранения.
Так, например, глупо занимать данными, которыми пользуются раз в год, дорогостоящее и быстрое дисковое хранилище. А иную информацию, например личные музыкальные файлы пользователей, может быть, вообще не стоит хранить на корпоративном сторадже.

Несколько лет назад разработанная идея “иерархического хранения”, сочетающего в себе системы как дискового, оперативного хранения, так и “менее оперативное” хранение на медленных и дешевых дисках, как, затем, и еще более медленные ленточные системы хранения, нашла свое применение в системах “жизенного цикла информации”.

В таких системах данные прозрачно для прикладных систем, в соответствии с определенными администраторами политиками, мигрируют с одних систем хранения на другие, оставаясь при этом доступными для пользователя.
Хорошими примерами системы иерархического хранения, на базе которого можно построить систему “жизненного цикла информации”, является EMC (бывший Legato) DiskXtender и компонент Tivoli - HSM - Hierarchical Storage Manager (ныне TSM for Space Management).
Также заметным игроком в этом сегменте является компания FileNet, в прошлом году приобретенная IBM.

Для хранения резервных копий традиционно применяются устройства на магнитной ленте - стримеры. Если объем информации, подлежащий хранению, превышает стандартную емкость картриджа или кассеты с лентой, то имеет смысл задуматься о покупке устройства для автоматической замены кассеты в стримере - авточенджера или библиотеки. Дешевые библиотеки на несколько кассет сегодня стоят 6-12 тысяч долларов, а удобство от их использования может быть весьма существенно при регулярной работе бэкапа (а именно регулярным он и должен быть!).
Обратите внимание, что традиционно для магнитных лент указывается величина “с компрессией”, под которой понимается некое условное число, вдвое выше ее физической емкости. Двукратная компрессия достаточно просто достигается при записи текстовых файлов, но если вы намереваетесь записывать уже скомпрессированные данные, например, дистрибутивы программ или фото-видеофайлы, которые уже сами по себе сжаты, то будьте готовы, что емкость ленты при этом уменьшится вдвое и будет равна ее физической емкости.

??з всего разнообразия лент и форматов записи в живой природе остались только:

DDS (ныне DAT) - традиционная “маленькая” кассета общей емкостью сегодня 72 и 160GB. Также распространены более старые версии, такие как DDS-3 и 4, меньшей емкости на кассету.
Под кассету этого формата, вследствие ее хрупкости, весьма редко встречаются авточенджеры и библиотеки. Как правило, это формат для “персонального бэкапа” содержимого одного сервера или небольшой организации.

LTO (2,3,4) ??ногда (в оборудовании HP) носит собственное HP-шное имя Ultrium. HP был одним из разработчиков этого формата.
Наиболее часто встречающийся в библиотеках формат, вытеснивший в настоящее время всех конкурентов в своем классе (SDLT). Кассета традиционно называется “картридж”, довольно массивна и прочна. Плотность записи и емкость одного картриджа увеличивается вдвое от поколения к поколению. Довольно дорогостоящий формат сам по себе, но на сегодня единственный выбор для серьезного применения в качестве ленточного носителя уровня предприятия.
Сегодняшние емкости на один картридж: LTO-2 - 200GB (некомпрессированной, физической емкости), LTO-3 - 400GB, LTO-4 - 800GB. Скорость записи-чтения - до 80MB/s.

Относительно редко, но все же встречаются:
VXA - сравнительно недорогой формат со множеством интересных технических решений, но мало распространен. Ориентирован на небольшие компании. ??ногда бывает трудно найти под него кассеты. Емкость кассеты - 160GB.
AIT - формат, продвигавшийся Sony, как многое из оборудования этой компании, “вещь в себе”. SAIT-1 - 500GB, AIT - 100GB.

Несмотря на то, что “дисковое храненение” переживает сейчас вполне объяснимый подъем, “старые добрые” ленточные библиотеки прекрасно себя чувствуют в своем сегменте - долговременном хранении огромных объемов, ведь по долговременности и стоимости хранения за мегабайт большие ленточные системы все еще непобедимы. Экономическая эффективность ленточных библиотек возрастает с увеличением их размера. Если маленькую ленточную библиотеку на пару десятков терабайт довольно легко заменить стораджем на дешевых SATA-дисках, то с большими ленточными библиотеками на многие петабайты дискам соревноваться все еще трудно.

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

Поэтому в областях длительного объемного хранения и offsite storage vaulting (хранения данных вне основной площадки обработки) крупные ленточные библиотеки все еще не имеют альтернатив.

Однако ленточным устройствам хранения присущи и серьезные недостатки, вызвавшие в последние годы подъем интереса к “дисковому бэкапу”, то есть резервному копированию с дисков на диски же, т.н. схема D2D.
Наиболее серьезный минус ленточных устройств обусловлен самим принципом записи. Это устройства последовательной записи и последовательного же чтения. Если нам нужен фрагмент данных, находящийся в середине ленты, нам надо вставить ленту, заправить ее в механизм, убедиться, что это правильная лента, прочтя ее заголовок, включить перемотку и домотать до приблизительно нужного места, включить считывание и дойти до нужного фрагмента, и только после этого мы получим наши данные.
Процесс чтения фрагмента может иметь задержку от момента отдачи команды на чтение до десятка минут. А представим теперь, что нам нужно таких фрагментов размером в пару мегабайт прочитать сотню, да еще из разных кассет?

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

Резкое удешевление жестких дисков в последние годы возродило интерес к резервному хранению на дисках, Disk-to-Disk, D2D.
Преимущества дисков по сравнению с лентами: они быстрые.
Поскольку диски являются, в отличие от лент, устройствами с “произвольным доступом”(random access), то считывание произвольного фрагмента “из середины” не требует последовательно добираться до него от самого начала диска.

Второе преимущество состоит в том, что дисковое хранилище можно сделать более надежным, чем лента, несмотря на то, что один отдельно взятый диск, как правило, менее надежный, чем картридж ленты. Делается это уже известным методом RAID - Redundant Array of Unreliable Independent Disks.
Попытки сделать “RAID на лентах” были (например, я видел это в CA ARCserve), но, к счастью для нашего мозга, эти попытки не распространились широко. В то же время RAID на дисках есть хорошо разработанное и широко использующееся решение.

Промежуточным вариантом, объединяющим достоинства (и нивелирующим недостатки), является довольно популярная комбинированная схема D2D2T, Disk-to-Disk-to-Tape.
В этой схеме в качестве промежуточного места хранения используется “дисковый буфер” на недорогой дисковой системе хранения, к которой, в свою очередь, подключено устройство хранения на ленте.

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

Современные системы резервного копирования и архивирования, как правило, умеют использовать схему D2D2T без дополнительных усилий.

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

К счастью, сегодня это, обычно, уже не так сложно. Большинство систем резервного копирования оснащены теми или иными “мастерами”-”wizards”, которые помогут вам настроить необходимый план резервного копирования.
Так, например, Symantec Backup Exec оснащен довольно удобной и развернутой помощью по этому процессу. К сожалению, общедоступная урезанная версия Backup Exec, вошедшая в состав сервера Windows под именем NT Backup, очень спартанская и заставит вас разбираться с планами резервного копирования самостоятельно.
Однако такова обычная плата за “условность бесплатности”. Впрочем, если вы решите в дальнейшем перейти от NT Backup к полной версии Backup Exec, то проблем с чтением бэкапов, сделанных в NT Backup, у вас не будет, все же это продукты одной компании.

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

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

В настоящее время крупные системы резервного копирования поставляются с комплектом агентов для ПО, либо включенных в базовую поставку, либо (как правило) поставляемых за дополнительную плату, в зависимости от того, что за данные в компании необходимо защитить.

Для хранения больших объемов резервных копий исторически наиболее часто используются магнитные ленты. Подробнее на магнитных лентах мы остановимся в третьей части обзора, пока же я хотел бы коснуться темы правильного использования лент.

Одним из недостатков магнитных лент, является их механический износ. Если не предпринять надлежащих мер, то отдельные картриджи магнитных лент, например, используемые для ежедневного инкрементального бэкапа, будут изнашиваться больше, чем другие, например, те, которые используются под архивное “годовое” хранение.
Для обеспечения правильного чередования (ротации) лент в библиотеке используются специальные алгоритмы, такие как “дед-отец-сын” или “ханойская башня”. Как правило, эти алгоритмы встроены в соответствующее ПО для резервных копий, управляющее ленточной библиотекой, и не требуют индивидуальной настройки. Заботиться об этом следует только в случае ручной смены кассет на небольших стриммерах. Рассчитайте и точно следуйте схеме смены кассет, чтобы не оказаться однажды с нечитаемым, из-за повреждений ленты, бэкапом в руках.

О необходимости создания резервных копий информации говорить можно много, но, к сожалению, как показывает мой опыт, ничто так не агитирует за серьезное отношение к бэкапу, как факт серьезной потери критичных данных (и весьма частые последующие “оргвыводы” в отношении “крайних”).
Ну, а пока это в вашей компании не случилось, давайте рассмотрим возможные методы и средства защиты.

Самое простое и самое понятное - так называемый Full Backup. Мы берем все наши данные и делаем их физическую копию. По окончании Full Backup мы будем иметь все наши даные в двух экземплярах, один - в оригинале, второй - в копии. Оба экземпляра полностью идентичны. Все просто и понятно - это плюс. Минус же заключается в том, что полная копия занимает ровно столько же места, сколько оригинал. Да и сам процесс создания копии может занимать значительное время. Хорошо если это папка “Мои Документы” вашего ноутбука, а если это полная копия терабайтного хранилища?
А ведь копию придется регулярно возобновлять, ведь если данные изменяются во время работы, то наша полная копия уже не будет копией. Значит ежедневно нам придется копировать терабайт во вторую копию, весь, целиком. А если мы хотим иметь несколько копий, например, позавчера и неделю назад? Готовьте место * N.
??так минусы: объем копирования - время, место и загрузка мощностей при копировании, а также большое количество занятого места при множественных копиях.

Логичный выход из затруднения - инкрементальный (incremental) бэкап. Если за рабочий день изменяется всего лишь малая часть данных, то можно после первого полного бэкапа сохранять только изменившиеся файлы.
Но как же мы найдем эти изменившиеся файлы среди тысяч имеющихся?
Тут на помощь к нам приходят так называемые “атрибуты файловой системы”, специальные битовые поля, которые указывают свойства файла. Когда задумывалась структура файловой системы, то для специальных признаков файла были предназначены “флаги”-признаки, принадлежащие файлу наряду с его именем и, например, расширением.
Атрибуты есть даже в такой примитивной файловой системе, как FAT.
Классический набор атрибутов это признаки “только для чтения” (он устанавливается, если операционной системе запрещено файл удалять или записывать в него), атрибуты “скрытый”, “системный”, а также атрибут под названием “archive” - “архивный”. Этот атрибут выставляет OS в том случае, если файл как-либо изменяется средствами OS.
Если мы, проводя резервное копирование, сбросим у всех файлов этот флаг, то как только какой-то из файлов будет изменен, то OS вновь устновит бит-”флаг” “archive” для этого файла. Если теперь мы просмотрим атрибуты, то все файлы с выставленным флагом archive - это те файлы, которые нам надо сохранить “в архив” в инкрементальной копии.
Конечно, после сохранения мы (вернее, наша программа резервного копирования) вновь атрибут сбросим.
Это самый простой способ определения файлов для инкрементальной копии, поддерживаемой средствами самой OS.

Таким образом, каждая резервная копия будет состоять из одной полной и множества инкрементальных копий.

Однако, резервное копирование делается не столько ради него самого, как такового копирования, сколько ради возможности быстрого восстановления информации из него. Как же будет выглядеть процесс восстановления в такой схеме?

Нетрудно видеть, что для восстановления в схеме Full Backup + Incremental нам будет нужно восстановить сперва Full, а потом последовательно восстановить на него содержимое всех сделанных с момента Full Backup инкрементальных копий.
Почему недостаточно только последней?

Допустим мы имеем на диске файлы A, B, C и D.
После создания полной копии, в которую попали все 4 файла, мы изменяем в понедельник файл A и B. В инкрементальную копию понедельника попадут два измененных файла A и B. Во вторник изменим файл C и занесем его в инкрементальную копию вторника, однако файла A и B не изменялись во вторник, а значит в задание на копирование для вторника они не попадут.
В среду наши данные оказались повреждены. Если мы восстановим полную копию, а затем только последнюю инкрементальную, то мы потеряем все изменения для файлов A и B понедельника, что, конечно же, никуда не годится.
Поэтому мы вынуждены считать и восстановить данные со всех инкрементальных копий.

По этой причине стратегия Full + Incremental характеризуется быстрым процессом копирования, но значительно более медленным восстановлением, чем в случае Full Backup, ведь нужно последовательно прочитать множество ежедневных копий.
По этой причине стараются ограничить количество инкрементальных копий (как бы ни было привлекательно с точки зрения бэкапирования ограничиться только ими) и производить периодические полные копии. Наиболее популярная и распространенная стратегия это: суббота после окончания рабочей недели - full copy, ежевечерне, по окончанию рабочего дня - incremental.

Однако, в последние годы ряд производителей ПО резервного копирования предлагает функцию “постоянного инкрементального бэкапа”, при котором софт резервного копирования самостоятельно собирает внутри себя из множества инкрементальных копий “контрольные точки”, “псевдо-full backup”. Так, например, работает Tivoli Storage Manager, эта функция иногда встречается теперь и в системах резервного копирования других производителей.

Логичным выходом из ситуации с последовательным восстановлением был бы вариант, когда последняя резервная копия несла бы в себе все измененные по сравнению с Full Backup файлы, то есть разницу между Full и текущим положением, при этом из примера сверху в первый день в нее также попали бы файлы A и B, а во второй - три: A, B и C.
Такая схема называется Differential. За счет некоторого увеличения объема копии мы экономим время восстановления, ведь нам нужно восстановить всего 2 копии, большую Full и одну, последнюю, Differential.
При работе с атрибутами файлов при методе differential атрибут “archive” после копирования не сбрасывается. Таким образом в ежедневную копию попадают последовательно все измененные сегодня и ранее файлы, пока не придет время нового Full Backup, который и очистит все атрибуты “archive”.

Выбор стратегии остается за администратором: что для него важнее - более экономный расход места и более быстрое завершение процесса копирования для метода incremental или более быстрый процесс восстановления за счет большего расхода места и времени для метода differential?

Еще один метод, часто встречающийся в ПО, это метод daily backup. При этом в такой “ежедневный бэкап” попадают файлы измененные за день. Для определения файлов, которые следует сохранить, используется как бит “archive” так и дата последнего изменения файла.

Однако большинство этих методов родилось в доисторические времена, когда пары флопиков было достаточно для хранения резервных копий.
Сложности стали возникать при резервном копировании больших файлов.
Например почтовая база MS Exchange или большая база данных есть некий весьма обширный, во много сотен мегабайт размером файл. Но даже если внутри этой базы изменился один символ или добавилось одно письмо в килобайт размером, мы будем вынуждены сохранить его в инкрементальной копии целиком, все много сотен мегабайт заново. Ведь с точки зрения OS файл - изменился, и файловая система взведет флаг “archive”.

Для выхода из этой ситуации входит в применение метод т.н. continuous backup, появившийся, например, в такой системе как Symantec (ранее Veritas) Backup Exec, и постепенно появляющийся также в других продуктах в той или иной форме.

При этом методе на OS устанавливается программа-агент, которая отслеживает операции ввода-вывода, и, работая на “блочном” уровне, передает каждый изменившийся блок, непосредственно после его изменения, в программу-сервер, уже не обращая внимания на примитивные атрибуты файла. Кроме возможности экономично бэкапить большие слабоизменяемые файлы, этот “гранулярный” метод позволяет также улучшить оперативность резервного копирования, ведь при этом резервное копирование получается “continuous” - непрерывное, производящееся непосредственно после изменения, а не раз в день вечером.

Основные игроки на этом рынке в настоящее время это:

ранее Veritas, а ныне, после покупки компании Veritas компанией Symantec - Symantec Backup Exec, ориентированный прежде всего на платформу Windows, и его “старший брат”, многоплатформенный и гораздо более дорогой NetBackup.

Legato, а ныне EMC Software и их продукт класса названного выше NetBackup - Networker (когда-то первая система сетевого резервного копирования вообще).

Относительно широко распространена система, входящая в семейство программных продуктов Tivoli компании IBM - Tivoli Storage Manager, характеризующийся традиционной для IBM широчайшим функционалом и запредельной сложностью в настройке ;)
Часть продуктов имеет локальную распространенность. Так сравнительно широко распространенный у нас в стране CA ARCserve стал популярен вследствие весьма щадящей лицензионной политики CA.
Немецкая компания Commvault производит относительно малоизвестный, но довольно интересный продукт Galaxy, сильной стороной которого является хорошая интеграция с продукцией Microsoft (Commvault когда-то был инженерным подразделением MS в Германии).
Характерный для компаний с присутствием французского капитала Atempo Time Navigator имеет те же корни популярности, что Kaspersky Antivirus или The Bat у нас в стране - это французская программа.
Ну и наконец рано или поздно Microsoft сам доделает свой Data Protection Manager v.2, и такой мощный игрок на рынке безусловно заставит почувствовать себя неуютно множество конкурирующих в этой области компаний.

Среди систем резервного копирования “персонального класса” следует упомянуть такие имена как Genie-Soft Backup Manager (которой пользуюсь я на своем десктопе) или Dantz Retrospect, некоторое время купленный EMC, с тем чтобы дополнить собой в сегменте начального уровня мощный, но дорогостоящий и сложный продукт Legato Networker. Возможно, эти программы и не столь мощны, как перечисленные выше, не умеют взаимодействовать с централизованным управляющим сервером и копировать данные на огромные медиа-библиотеки, но вполне справляются с задачей защиты данных локального настольного компьютера или ноутбука.

Еще почитать по теме:

Symantec Backup Exec

EMC Software Networker

Tivoli Storage Manager

CA ARCserve (а также российский “фэн-сайт“)

“Профессия - журнализд” ;)

По-видимому, мне все же придется сказать тут несколько слов о пресловутом “иске NetApp к SUN, в котором они хотят запретить Solaris”. К сожалению, эта история шумно “освещается” в различной компьютерной прессе и создает множество непониманий и беспричинных возбуждений в среде IT-шников.

Если пойти к доступным нам первоисточникам, а именно к блогам Джонатана Шварца (CEO SUN) и Дейва Хитца (vice-president and co-founder of NetApp), то картина выглядит следующим образом:

Обычной практикой американских компаний является так называемое “кросс-лицензирование”. Патенты, которые задумывались как средство “слабого против сильного”, долженствующее защищать права мелких авторов и разработчиков против корпораций, в настоящее время полностью исказили свой изначальный смысл. Сегодня крупнейшие держатели патентов - крупные корпорации - получающие их, среди прочего, в результате практики “кросс-лицензирования”.
Корпорация “Big Three Letters, Inc” обнаруживает на рынке небольшую компанию “Basile Pupkin Systems LLC”, среди продуктов которых юристы компании находят что-нибудь, нарушающее один из имеющихся в корпорации тысяч патентов. Это нетрудно, поскольку многие патенты бывают сформулированы очень расплывчато и общо: “способ вывода рекламы в интернете с помощью небольших автоматически открывающихся окон вывода демонстрации”, “способ демонстрации эмоционально окрашенных текстовых сообщений с помощью графических значков эмоций”.
Мелкой компании делается “предложение, от которого невозможно отказаться”, а именно: “Мы подаем на вас иск за нарушение Intellectual Property на $$$$$$$, наш law department скучает, и ему как раз хочется на ком-нибудь потренировать стажеров, либо мы заключим мировое соглашение, вы получите право использовать наши патенты в вашем продукте, а за это вы передадите нам права использовать другие ваши патенты.”
Ответ, как правило, очевиден.
“Big Three Letters, Inc” получает в свой огромный portfolio несколько новых патентов, а “Basile Pupkin LLC” за это получает спокойную жизнь.
Далее история повторяется со следующей компанией.

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

Когда SUN покупал в 2006 году компанию-производителя ленточных и дисковых систем хранения StorageTek, NetApp намеревался выкупить часть кросс-лицензированных патентов, связывавших эти компании, однако SUN этому воспрепятствовал.

Вскоре SUN подал иск о нарушении компанией Network Appliance своих Intellectual Properties, относящихся к области действия ряда патентов.

Обычной практикой в юридическом мире является подача так называемых “встречных исков”:
“Джон Доу против Макдональдс. ??ск подан, поскольку у стаканчиков кофе Макдональдс дурацкие крышки, и я не могу их открыть не пролив кофе”, встречный иск “Макдональдс против Джона Доу. С требованием запретить продавать кофе в стаканчиках безруким инвалидам”. Оба иска разбираются, и в результате первый выигрывает один, второй - другой. В целом lawers с обоих сторон поднимают немного денег и занимаются делом.
Так устроена общепринятая юридическая американская практика.

??так, в 2006 году компания SUN потребовала у NetApp ~36 миллионов $ за “нарушение патентов”, приобретенных вместе со Storagetek.
Поскольку за прошедшее время достигнуть мирового соглашения с SUN не удалось, NetApp подал встречный иск по описанной выше формуле, так как, очевидно, в результате получившегося кросс-лицензирования, обе компании в равной мере нарушают права друг друга.

Тут нет правых и виноватых, тут нет повода для паники, это обычная, повседневная деятельность юридических департаментов крупных американских компаний, которые этими взаимными исками, зачастую тянущимися годами, как правило и занимаются все свое рабочее время.

Совершенно неясно какой в этом “информационный повод” (кроме повода привлечь внимание прессы к ZFS и JAVA SUN) и почему спустя более чем полтора года после начала тяжбы со стороны SUN к NetApp, после подачи встречного иска NetApp к SUN, они решили привлечь к этому делу внимание прессы.

Позволю себе процитировать Дейва Хитца, слова которого к работникам NetApp были опубликованы у него в блоге:

“If your job is to cooperate with people from Sun, then keep on cooperating with them! Be nice to them. Aside from the small team whose job is to work on this lawsuit, I hope that employees can mostly ignore it.”

“Если ваша работа связана со взаимодействием с людьми из SUN, то продолжайте работать с ними (как и прежде)! Проявляйте уважение к ним. Помимо небольшой группы, чья работа связана с этим иском, надеюсь, что остальные сотрудники могут проигнорировать его.”

Дополнительная информация по теме:

Блог Дэйва Хитца

Блог Джонатана Шварца (eng) (русский)

??так, как говорится в шпионских романах, “теперь об этом можно рассказать”.
То, о чем многие уже догадывались по слухам, разговорам, утечкам в прессу и предложениям компаний-партнеров NetApp, официально объявлено вчера.

Компания NetApp представила свои новые модели в сегменте mid-size and low-enterprise, так называемую “FAS2000 series”.

Несмотря на то, что партнерам информация была доступна с начала лета, и даже в конфигураторе эти системы присутствовали, информация по ним была до вчерашнего дня закрытой.

Вот что теперь у нас есть:

.
Это полностью новая платформа, разрабатывавшаяся достаточно длительное время в недрах NetApp до этого момента.
Сильным решением, в первую очередь, следует назвать использование дисков SAS (3.5″, 15KRPM) вместо традиционных для NetApp дисков FC. Это позволит ориентировочно понизить общую стоимость укомплектованной системы хранения на 10-15% при сравнимом с FC быстродействии.

Для использования этих дисков разработана новая “коробка”, а вернее две новых “коробки”: для FAS2020 высотой 2U и для FAS2050 4U. Диски в них размещаются горизонтально, что тоже новинка для NetApp (ранее такая схема размещения была только у отдельной разработки NetApp, системы для SMB-рынка StoreVault S500).
До этого, как вы помните, системы FAS200 имели 3U высоты при 14 дисках. То есть мы еще и драгоценное место в стойках выигрываем.

Вот как они выглядят:

Вид, так сказать, сзади (для ценителей geek porn ;) :

Порты слева направо:
2 шт. 4Gb FC, консоль, remote LAN management port, 2 шт. GigE port.
Над портами в FAS2050 слот расширения PCI-Express (дополнительные порты FC или GigE).

Главная “жертва” для FAS2020 это CX3-10 и MSA1500cs, для FAS2050 - CX3-20 и EVA4000 (ну и AMS200, по-видимому).

Таким образом, новые модели накрывают разрыв между entry-level и enterprise системами ряда FAS3000. Причем подбираясь к младшим FAS3020 практически вплотную. А с учетом 4GB интерфейсов у FAS2000 при равном с FAS3020 их количестве, равном количеством кэш-памяти (4GB) и небольшой практической разнице в предельно допустимой емкости (69 против 84TB) это еще надо посмотреть, кто у нас теперь больше энтерпрайз. ;) Учитывая все возможные варианты комплектации систем, все это дает по настоящему беспрецедентную гибкость решений от NetApp.
По производительности системы FAS2000 series довольно точно заполняют промежуток между самой старшей системой старой “серии 200″, FAS270 и FAS270C, и самой младшей системой “серии 3000″ - FAS3020.
При этом старая линейка FAS200 остается в строю еще достаточно продолжительное время.

Официальная страничка продукта (на русском языке)

Официальный даташит (на русском языке)

Технические спецификации (на русском языке)

?? вообще, не могу не отметить, что вебсайт NetApp уже во многих местах заговорил по-русски. То, что российский NetApp тем самым становится ближе к своим клиентам, не может не радовать, пусть даже за многими ссылками скрываются пока англоязычные материалы и непереведенные странички, но тенденция правильная, хорошую и полезную работу делаете!

Прежде всего выбор NAS-протокола определяется принадлежностью IT-инфраструктуры, использующей NAS-устройство, к одному из двух «царств» - «Windows» или «UNIX».
«Родной» (native) протокол для Windows – CIFS, для UNIX (Linux, Solaris, AIX, FreeBSD и т.п.) – NFS. Конечно, в большинстве OS существует поддержка протоколов соседнего «царства». Так, например, NFS для Windows поставляется в бесплатном ныне продукте MS Services for UNIX 3.5 (SFU, бесплатно скачивается с вебсайта Microsoft) или SAMBA (www.samba.org, включен ныне в большинство дистрибутивов UNIX) для поддержки CIFS на UNIX. Но, разумеется, родной протокол для системы почти всегда предпочтительнее, хотя бы просто из соображений минимизации настроек и инсталляций, а значит ошибок администраторов и неожиданных проблем с производительностью.

Stateless и Stateful протоколы. Что это и чем грозит.

Протоколы файлового доступа NFS и CIFS, кроме принадлежности к двум «лагерям» UNIX и Windows, различаются также принципиальной разницей способов обращения к данным: т.н. stateless и stateful.
NFS это протокол stateless. Это означает, прежде всего то, что он по своей природе не сохраняет состояние соединения, и каждое обращение к файлу начинается «как с чистого листа». Причиной этого было то, что NFS изначально создавался как протокол доступа к данным по априори ненадежным, «глобальным» сетям. Между обращениям к файлу мог случиться обрыв и восстановление соединения, маршрут к файлу, с точки зрения сети, мог поменяться (что нормальная ситуация для TCP-сети). Все это не должно было оказывать влияния на процесс доступа к данным.
Для правильной обработки таких ситуаций была выбрана так называемая «stateless» модель соединения. При этом каждое обращение делается предполагая, что состояние соединения не сохраняется или не известно. Операция изменения байта в файле производится как «обратиться к файлу – проверить его существование – открыть файл на запись – записать байт – закрыть файл». При этом между операциями файл может исчезнуть, быть вновь создан, переместиться на другое устройство и так далее. С точки зрения протокола NFS это совершенно неважно. Состояние соединения между приложением и его файлом не хранится, и каждое соединение создается заново. Казалось бы излишние усилия и накладные расходы? Однако при общей аскетичности NFS как протокола (а создавался он еще во времена, когда модем на 2400 бод был вполне приемлемым средством доступа к данным), во многих случаях эти дополнительные операции с файлами не слишком обременяют процесс.

CIFS – Common Internet File System - Обобщенная ??нтернетная Файловая Система (также ранее известный как SMB – Server Message Blocks - Блоки Сообщений Сервера) рожден уже в наше время. ??значально он разрабатывался как сетевой протокол, применявшийся в среде системы Microsoft LAN Manager, сперва для DOS, а потом для Windows, как совместная разработка MS и IBM. Унаследовав технологии LAN Manager и его протокол SMB со времен DOS, войдя в новую OS Microsoft Windows и пройдя длинный путь развития, протокол был стандартизирован в 1987 году в IETF (RFC1001, RFC1002, IETF STD 19) под названием CIFS.
Это более сложный, чем NFS, протокол. Его область применения это уже гораздо более надежная LAN. Она позволила выбрать для него во многом более выгодную модель «stateful», при этом соединение будучи открыто, например, подразумевается открытым, его состояние сохраняется в OS, и оно не требует для каждой записи проходить все операции с самого начала: «проверили существование – открыли – записали байт – закрыли». Однако вследствие того, что NFS протокол более простой, и во многих местах даже примитивный (не забудьте, для какой среды он изначально проектировался), зачастую в ряде случаев он, несмотря на все дополнительные «накладные расходы», оказывается более быстродействующим. А для операций, связанных, например, с переподключением хранилища данных в кластерной или иной отказоустойчивой конфигурации, еще и более предпочтительным, за счет того, что изначально предполагает соединение между потребителем данных и его источником ненадежным и способным исчезнуть или измениться в любой миг.

Для использования NFS в среде Windows можно использовать бесплатно распространяемый ныне Microsoft продукт MS Services for UNIX (SFU), в который включен клиент для NFS. Поддержка протокола NFS для среды UNIX же обычно включена по умолчанию во все дистрибутивы.
Поддержка же CIFS в среде UNIX осуществляется через продукт под названием SAMBA, это результат reverse engineering-а сетевого обмена протокола и воссоздания средств использования протокола в независимом свободно распространяемом продукте. Такое непростое и чреватое будущими проблемами совместимости решение было выбрано потому, что, несмотря на свою стандартизацию в IETF, протокол CIFS закрыт и является собственностью Microsoft, что ограничивает его использвание в ряде случаев в продуктах т.н. «свободного программного обеспечения» (GNU). Официально лицензией на его использование владеют в настоящий момент два крупнейших производителя NAS, такие как Network Appliance и EMC. Лишь только они используют полнофункциональный протокол CIFS в своих независимых от MS продуктах. Остальные вынуждены либо использовать SAMBA, либо применять для него версию Windows Storage Server, несущий в себе CIFS по умолчанию.

43% of companies that experience disaster never re-open, and 29% close within two years (McGladrey and Pullen).
93% of business that lose their datacenter for 10 days go bankrupt within one year
(National Archives & Record Administration).

“43% компаний, испытавших катастрофическое нарушение работоспособности, уже не возобновляют работу, а 29% закрываются в течении следующих 2 лет.
93% предприятий, терявших доступ к данным своего датацентра на 10 дней, заканчивали банкротством в течении 1 года”

?? даже несмотря на бытующее мнение: “Да что нам эти слабаки и их пресловутый Chapter 11 ‘Закона о банкротстве и защиты от кредиторов’!” - стоит задуматься. Ну пусть наш бизнес суровее и гораздо устойчивее, но все равно, цифры говорят сами за себя.

 Впрочем у нас и дизастеры свои собственные: приход ‘масок-шоу’ и изъятие серверов (почты, баз данных) “для обеспечения следственной деятельности” дело во многих отраслях, ну если не обычное, то по крайней мере привычное. Куда там землетрясениям с торнадо и терактами, у нас тут собственный, “русский дизастер”. Также как известные события осени 2001 в мире подтолкнули многие компании к разработке стратегии защиты от катастроф (disaster recovery), так и печальная судьба одной нефтяной компании в России заставила многих задуматься о защите данных, о “непрерывности ведения бизнеса” и его устойчивости в неблагоприятных условиях.

??стория из жизни:
Теряет по вышеописанным причинам некая компания пул серверов электронной почты MS Exchange. “Не беда”, думает она, “мы компания с менеджментом, сертифицированным по ISO9001, у нас все по науке, и ежедневные бэкапы всех данных”. Начинают восстанавливать данные из бэкапов, а они, хоба, и не восстанавливаются.
Просто никто никогда не проверял, а можно ли на самом деле восстановиться из забэкапленных данных.

Резервное копирование данных еще не значит наличие при этом “резервного восстановления”.
А вы, мой читатель, давно ли проверяли, проходит ли Restore из вашего Backup?

??так, мы рассмотрели отличия и основные методы применения NAS- и SAN-устройств в IT-инфраструктуре. Становится очевидно, что в реальной жизни не только встречаются как задачи для NAS, так и для SAN, но и, более того, они встречаются одновременно в рамках той же самой IT-инфраструктуры предприятия.

Как же обычно выходят из ситуации необходимости одновременного использования NAS и SAN?
Обычный способ - это использовать “более низкоуровневый” SAN-storage, и, сделав на нем дисковый раздел, подключить его к внешнему серверу (Windows или UNIX), играющему в данном случае роль NAS-гейта. Часто подобные решения продаются как дополнительные к более крупным решениям того или иного вендора (например, HP Storage Server или HDS NAS device или же вовсе клиентский “самосбор” с использованием Linux и SAMBA).
Однако тут имеет смысл не забыть посчитать, во сколько обойдется такое “вспомогательное решение”, ведь денег будет стоить не только серверная платформа, предназначенная под NAS-gate, но и клиентские лицензии под Windows (о чем в нашей стране принято “забывать”) или же время (которое, согласно Бенджамену Франклину - деньги), потраченное на отладку и оптимизацию SAMBA-сервера.
Не секрет, что такие вещи, как SMB signing, аутентификация Kerberos, иерархические домены NT, поддержка некоторых возможностей ActiveDirectory, подчас существуют в SAMBA в достаточно сыром варианте реализации, либо требуют, как показывает практика, углубленного “чтения манов”, исследований и дискуссий в разнообразных open software communities.

Совсем все невесело становится, если NAS оказывается в компании по-настоящему business critical ресурсом. Очень часто живописное разъяснение сисадмину того, что именно является в компании business critical, осуществляет, например, исполнительный директор компании, который не может открыть какой-нибудь из своих файлов Очень Важных Презентаций или Победных Квартальных Отчетов С Графиками на собрании акционеров или совета директоров. ;)
Так или иначе, но как правило IT-инфраструктура компании всегда использует оба варианта доступа к данным, хотим ли мы, интеграторы и сисадмины, этого или нет.

Однако компания NetApp одной из первых задумалась над возможностью предложить рынку действительно универсальное устройство хранения, совмещающее в себе как SAN, так и NAS функционал, работающий одновременно.

В отличие от большинства вендоров сетевых систем хранения, представленных на сегодняшнем рынке, NetApp начинал как производитель Enterprise NAS-систем, которые впоследствии стало возможно использовать и как SAN системы по протоколам FC и iSCSI, в 2003 году добавившимся к традиционным для систем NetApp NAS-протоколам CIFS и NFS.

Концепция Unified Storage в системах хранения NetApp позволяет использовать систему хранения NetApp одновременно как SAN, так и как NAS, в зависимости от того, какие лицензии на доступ введены. Такой подход позволяет выбирать для каждой задачи оптимальный метод ее решения. Ведь зачастую в каждой компании существуют задачи как одного, так и другого типа. Unified Storage представляется близким к идеалу решением задач консолидации хранения в прежде разрозненной информационной системе такой компании.

Типовая система хранения NetApp имеет установленные “на борту” как FC-порты для SAN-доступа по протоколу FibreChannel, так и Gigabit Ethernet, которые могут использоваться для организации доступа по iSCSI или NAS-протоколам CIFS или NFS. При этом желаемая комбинация из протоколов доступа может выбираться произвольно в соответствии с приобретенными и активированными в системе лицензиями.

Аналогичное решение сейчас продвигает и EMC в своей линейке Celerra NS, однако, без сомнения, решение NetApp на сегодняшний день более законченное, “взрослое”, производительное и совершенное.

Широкораспространенное заблуждение, что SAN в системах NetApp реализован через “эмуляцию” и файловый доступ, на деле не соответствует действительности. Корни этого заблуждения лежат в том факте, что если мы разместим на томе данных раздел (LUN) для SAN-доступа и затем обратимся к этому разделу как к сетевой папке NAS, то мы увидим там наш LUN в виде файла.

На самом деле речь идет только о “представлении” данных.
Чтобы лучше понять, что при этом происходит, привлеку аналогичную ситуацию из мира UNIX. Любому сисадмину UNIX-like систем известно, что “в UNIX всё файлы” и в каталоге /dev мы можем видеть разнообразные девайсы компьютера выглядящие как файлы.

Но из того, что мы видим устройство “CPU” или “последовательный порт” в виде файла, совершенно не следует, что последовательный порт или даже процессор в системе UNIX сделан через файловую эмуляцию. Просто OS представляет устройство в виде файла, даже если это устройство таковым физически и не является. Это всего лишь “представление”.

Так и в системах NetApp файловая и блочная семантика находятся на “одном уровне” архитектурной модели, и никто никого не эмулирует. Однако “глядя со стороны NAS” мы можем видеть блочное устройство “в терминах файловой системы”, то есть в том единственном виде, в котором нам его и может показать файловая система - в виде файла.

Таким образом, подход NetApp, при котором система хранения, не имея строго говоря никакой “обязательной программы” опций, конфигурируется согласно требованиям бизнес-задачи и, более того, может продолжать конфигурироваться и расширяться уже будучи установленной в продакшн, очень разумен и привлекателен с точки зрения IT-департамента.
Так мы можем приобрести систему в минимальной конфигурации, только с бесплатным протоколом iSCSI, и по мере развития IT-инфраструктуры, увеличения ее требований (и выделения на это бюджета), добавлять к ней все новые возможности, например, по защите данных приложений, репликации, или дополнительные протоколы доступа к данным - то, что в большинстве систем хранения конкурентов требует, как правило, покупки нового “железа” и длительного, мучительного переноса данных на него.

Модульная “универсальная система хранения” NetApp FAS в данном случае не диктует вам решение, но готова подстраиваться под задачи использующей ее компании.