Теряли ли вы когда-нибудь данные в результате технической аварии? Была ли среди них критическая информация, которая восстанавливалась медленно или только частично? Именно в такие моменты в команде впервые начинают думать о резервировании. Предлагаем изменить подход и заранее корректно организовать резервные ресурсы.

Продукты Nexign работают в системах с большим объемом информации разных типов. Зачастую это критически важные данные с большим риском для бизнеса в случае их потери. Поэтому для нас резервирование — это не просто опция по желанию, а практически необходимое требование к эксплуатации систем.

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

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

Знакомимся с понятием резерва поближе: структура, типы, объекты

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

Что такое резерв информационной системы? Это совокупность правил организации хранения данных, расположения оборудования и настроек программного обеспечения, которые обеспечивают как сохранение целостности данных, так и бесперебойную работу системы. Соответственно, резервирование — процесс создания резерва и контроля за его работой.

Предлагаем читателям проанализировать свои системы и отметить те пункты, которые к ним относятся:

длительное хранение любых необходимых для процесса данных (большая доля риска инцидентов с течением времени);
хранение критичных для процесса данных (риск утраты работоспособности важных частей системы или системы в целом);
хранение постоянно обновляющихся данных (риск утери актуальных изменений в системе);
беспрерывная работа для выполнения бизнес-целей системы.

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

Вспомним, что для оценки отказоустойчивости любого сервиса есть общепринятые показатели точки восстановления и времени восстановления:

RPO — Recovery Point Objective

RTO — Recovery Time Objective

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

В структуре резерва информационной системы можно выделить:

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

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

Объекты резерва также бывают разными:

Резерв программного обеспечения и оборудования.
С точки зрения расположения оборудования, на котором работает программный код и хранятся данные, резерв бывает локальный (все сервера в одном помещении) и географический (георезерв — разнесенные по дата-центрам площадки), который позволяет учесть дополнительные аварийные факторы.
Резерв данных.
Резервирование данных может работать в онлайн- и оффлайн-режимах. Для режима онлайн часто применяют термин «репликация», для оффлайн-режима — «бэкап», то есть резервное копирование.

Репликация обеспечивается, как правило, внутренними средствами и возможностями самого сервиса. Она позволяет переключиться на резервные сервера и быстро восстановить работоспособность системы, если вышло из строя оборудование основной части серверов, либо они недоступны из-за сетевой аварии.

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

Резерв информационных потоков.
При резервировании информационных потоков используют балансировщики на основе haproxy, nginx, Apache, аппаратные балансировщики, например NetScaler. Их основное назначение с точки зрения резерва — переключение потоков на резервную площадку в случае потери работоспособности основной части системы. За счет этого обеспечивается непрерывность работы.

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

Active-Active

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

Active-StandBy

Нагрузку информационных потоков принимает только основная часть системы. При падении основной части резервная часть системы автоматически принимает все потоки на себя.

Active-Passive

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

Например, база данных Oracle переводится на StandBy ноду вручную с контролем результата. Сохранение целостности данных на резервной ноде обеспечивается непрерывно внутренними средствами Oracle в процессе работы базы (репликация). Есть варианты архитектуры для Oracle, где используется DNS-балансировщик для нескольких Primary нод, с автоматическим распределением нагрузки через Oracle ClusterWare. Отдельно можно упомянуть технологию Oracle RAC, которая помогает восстановить работоспособность в случаях выхода из строя части оборудования. Таким образом, система может сочетать в себе различные варианты работы резерва.

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

Для разных узлов системы предусмотрены и распределенные сервера, и балансировка информационных потоков, и резервное копирование данных — как репликацией, так и путем создания резервных копий. Причем одной репликации для полноценного резерва одной и той же части системы иногда недостаточно, бэкапы также бывают необходимы. Исключение (либо правило) составляют кластеры серверов, внутри которых самостоятельно поддерживается целостное состояние данных. Например, для технологии S3 или Tarantool бэкапы данных с серверов не имеют смысла.

Какие есть решения для резерва файлового хранилища

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

Это группа серверов (файловые сервера), куда помещают любую требующую хранения информацию, формируемую при эксплуатации информационных систем компании. Потребителями такого файлового сервиса могут быть непосредственно сотрудники компании, а также другие интегрированные с хранилищем информационные системы.

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

Сейчас во многих случаях подобный сервис организуется с помощью технологии S3 Amazon. Такое хранилище при этом называют даже не файловым, а объектными, так как данные в нем хранятся в структурированном формате, и называются объектами. О данной технологии сейчас много информации на просторах сети, поэтому углубляться в подробности ее организации не будем, ограничимся только следующей схемой:

Для работы S3 в продуктивной среде требуется кластер из минимум 5 серверов, желательно физических, а не виртуальных, а также несколько балансировщиков.

Не всегда для потребностей бизнеса требуется хранилище подобных масштабов со всей инфраструктурой «железа» и программного обеспечения для поддержания его бесперебойной работы и сохранности данных. Бывает так, что для взаимодействия предприятия с сегментом партнеров B2B требования к объему хранения данных и производительности доступа к ним могут быть гораздо скромнее, чем для работы с сегментом B2C. Так, потребителями информации на файловых серверах могут быть непосредственно сотрудники компании, поэтому количество запросов к сервису относительно невелико и распределение файлов по категориям частоты их применения для ускорения доступа, как в S3, теряет смысл.

Допустим, на файловый сервер выкладываются финансовые отчеты, итоговые акты и другие документы, состояние которых на момент их формирования в системе необходимо хранить в течение условленного времени. В такой ситуации может быть достаточно организовать файловое хранилище на существующей минимальной инфраструктуре предприятия на группе серверов под управлением Windows Server, где резервирование между серверами обеспечивается технологией DFS — Distributed File System (распределенная файловая система).

Настройка хранилища под управлением DFS

DFS — это один из группы сервисов Windows, предназначенных для обеспечения работы файловой системы и хранилища, который позволяет реплицировать файлы и структуру папок между серверами. Согласно документации Microsoft, DFS поддерживается на каждой версии Windows Server с 2008 по 2022.

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

Схема для хранилища с использованием DFS выглядит менее масштабной, чем для S3:

Доступ к такому файловому хранилищу осуществляется по протоколу SMB (Server Message Block), который отличается от протокола S3.

SMB и его разновидность для linux — CIFS (Common Internet File System) — протокол приложений, который используется для удалённого доступа к файлам, принтерам и другим сетевым ресурсам.

Для Windows-пользователей взаимодействие по SMB позволяет удобно работать с общедоступными сетевыми папками единообразно с другими папками в Проводнике, то есть без использования дополнительного программного обеспечения. При этом не требуется конфигурация каких-либо дополнительных сетевых доступов.

При интеграции с таким файловым ресурсом других информационных систем можно использовать как SMB (или CIFS в зависимости от операционной системы), так и FTP (внутри сети) и SFTP.

Примечание:

Для организации взаимодействия других внешних сервисов по SMB/CIFS необходим сетевой доступ от хостов сервисов до файловых серверов по портам сетевого протокола TCP 139, 445.

При этом есть возможность настроить пространство имен в домене для удобства обращения к файловому хранилищу (можно настроить несколько, для разных файловых сервисов). Пространство имен — это единая точка входа на файловые сервера, которая имеет вид: \\<имя домена.ru>\<наименование сервиса>\<ссылка на общедоступную папку>.

Тогда вместо указания реального имени или IP одного из файловых серверов \\someservername.ru\somefolderlink\ или \\192.168.1.1\somefolderlink\ пользователи смогут подключаться к общедоступной папке в Проводнике вот так \\somedomain.ru\somesystem\somefolderlink :

Сервисы, работающие на linux-системах, могут подключаться к файловому серверу через смонтированный внешний ресурс, ссылающийся на общедоступную папку, как напрямую на одном из файловых серверов, так и через пространство имен в домене. Пример смонтированной «шары»:

[root@server ~]# mount | grep cifs

//file-server.somedomain.ru/shared-folder/ on /mnt/share type cifs (rw,relatime,vers=3.0,cache=strict,username=user,domain=somedomain,uid=232,forceuid,gid=232,forcegid,addr=10.0.0.1,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

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

Примечание:

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

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

С точки зрения разработки прикладного программного обеспечения, которое может использоваться для интеграции сервисов по протоколам S3, SMB, FTP, SFTP, нет принципиальных отличий в коде при обработке этих протоколов для разных языков программирования. Для вызова API S3 есть свои библиотеки. Например, для Java это пакет com.amazonaws, для Python — SDK boto3, аналогичные библиотеки есть и для работы с API остальных протоколов, их использование прозрачно и хорошо документировано. Поэтому не будет разницы в затратах на интеграцию с файловым сервисом S3 или DFS, в том числе при варианте разработки интеграционных программ внутри компании.

Но для работы пользователей с файловым хранилищем через пользовательский интерфейс в случае S3 потребуется дополнительная оснастка, чтобы они могли авторизоваться и видеть список необходимых им документов в привычном user-friendly виде. Из практики — некоторое программное обеспечение, которое используется для этого, иногда работает нестабильно. Чего не скажешь про Проводник, который можно использовать для серверов на DFS, как описано выше.

Технические аспекты настройки DFS

Настройка DFS начинается со следующих действий:

должны быть открыты сетевые доступы между файловыми серверами группы по портам сетевого протокола TCP для протоколов приложений RPC и SMB: 135 и 445, а также динамически выделяемым портам: >1024 (при необходимости можно выделить только статический порт для работы DFS из диапазона);
в домене нужно создать пространство имен и группу репликации, указав какие папки на сервере будут реплицироваться (то есть будут зеркальными копиями друг друга);
у пользователей Active-Directory должны быть права на управление серверами группы репликации.

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

После этого можно будет через оснастку DFS управлять переключением реплицируемых серверов, подключившись к операционной системе любого файлового сервера из группы (в рассматриваемом ниже примере в группе всего два файловых сервера). Для этого на сервере надо запустить Server Manager, далее открыть DFS Management и добавить для отображения пространство имен и группу репликации:

Примечание:

Оснастка DFS Management в этом примере используется для просмотра и управления уже созданными предварительно на уровне домена объектами, поэтому при выполнении указанных выше действий не создается каких-либо дополнительных сущностей, они только отображаются для возможности управления ими.

В пространстве имен будет видно, что статус основного сервера из группы файловых серверов — Enabled. Это означает, что указанная выше ссылка вида \\somedomain.ru\somesystem\somefolderlink будет перенаправлять запросы к ней на этот сервер, выбранный основным.

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

С учетом указанных ролей серверов в группе, схему хранилища DFS, представленную в прошлом разделе, можно изобразить так:

При этом, если на сервере, который находится в режиме read-only, попытаться создать внутри реплицируемой папки файл или каталог, то будет отображаться сообщение об отсутствии доступа Destination Folder Access Denied, так как правила репликации запрещают это действие:

В случае если основной сервер по какой-то причине стал недоступен (например, авария на сети), нужно:

1. Последовательно в пространстве имен поменять статус основного сервера на Disable Folder Target, а основным сделать второй сервер — Enable Folder Target.

2. В группе репликации поменять местами права на чтение и запись для основного и резервного серверов: сначала для основного Make read-only, затем для резервного Make read-write.

В дополнение к этому рекомендуется принудительно выполнить через командную строку на сервере:

dfsradmin membership set /RgName:<имя группы репликации> /RfName:<имя каталога репликации> /MemName:<имя сервера-участника группы, которого делаем основным> /IsPrimary:True

Если не выполнить действия из данного пункта, то ссылка \\somedomain.ru\somesystem\somefolderlink будет указывать на сервер, который все еще считается резервным в группе репликации, и при записи пользователями новых файлов на ресурс будет отображаться указанная выше ошибка доступа.

После действий по переключению в течение нескольких минут (в зависимости от настроек группы репликации) автоматически начинается репликация.

Также форсировать выполнение репликации можно командой на каждом сервере:

Dfsrdiag Pollad /Member:<имя сервера-участника группы>

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

Примечание:

При репликации через DFS синхронизируются в том числе права пользователей Active-Directory на структуру папок и файлы. На резервном сервере права устанавливаются такие же, которые назначены на соответствующие объекты на основном сервере.

Контроль выполнения репликации

Для проверки статуса репликации на каждом сервере можно использовать команду:

dfsrdiag ReplicationState /member:<имя сервера-участника группы> /all

Пример ответа в случае выполняющейся в настоящее время репликации (видно, что репликацией обработаны три файла с изменениями):

Active inbound connection: 1
Connection GUID: 9223E956-A416-4738-A523-29F30E0072D2
Sending member: <имя сервера-участника группы>
Number of updates: 3

Updates being processed:
[1] Update name: somefilename1.xlsx
Path : Not available
UID : {5F151750-C92F-4797-9FW3-51DBD6115DAD}-v15434700
GVSN : {5F151750-C92F-4797-9FW3-51DBD6115DAD}-v15624700
Parent UID : {5F151750-C92F-4797-9FW3-51DBD6115DAD}-v15432200
Replicated folder : CCB7QD7C-E630-4772-929C-354G912NF508
[2] Update name: somefilename2.xlsx
Path : Not available
UID : {5F151750-C92F-4797-9FW3-51DBD6115DA1}-v15434701
GVSN : {5F151750-C92F-4797-9FW3-51DBD6115DA1}-v15434701
Parent UID : {5F151750-C92F-4797-9FW3-51DBD6115DA1}-v16234555
Replicated folder : CCB7QD7C-E630-4772-929C-354G912NF508
[3] Update name: somefilename3.xlsx
Path : Not available
UID : {5F151750-C92F-4797-9FW3-51DBD6115DA1}-v15434702
GVSN : {5F151750-C92F-4797-9FW3-51DBD6115DA1}-v15434702
Parent UID : {5F144750-C92F-4797-9FW3-51RBD6115DA3}-v16234525
Replicated folder : CCB7QD7C-E630-4772-929C-354G912NF508
Total number of inbound updates being processed: 3

Total number of inbound updates scheduled: 0

Summary

Active inbound connections: 1
Updates received: 3

Active outbound connections: 0
Updates sent out: 0

Operation Succeeded

Также за ходом репликации можно следить в системном журнале на всех серверах-участниках группы репликации.

Так, после переключения ролей серверов, в нем будут следующие события:

4620 — The DFS Replication service has detected that <реплицируемая директория>, which used to be a read-write replicated folder has now been configured to be a read-only replicated folder. The DFS Replication service will not allow any changes to be made to the contents of this replicated folder. Any updates occurring on other read-write replicated folders will be replicated in and applied to the contents of this read-only replicated folder.

4622 — The DFS Replication service has detected that <реплицируемая директория>, which used to be a read-only replicated folder has now been configured to be a read-write replicated folder. The DFS Replication service will now allow any changes to be made to the contents of this replicated folder. Any updates occurring on this read-write replicated folder will be replicated out and applied to the contents of other replicated folders on other members.

4102 — The DFS Replication service initialized the replicated folder at local path D:\<реплицируемая директория> and is waiting to perform initial replication. The replicated folder will remain in this state until it has received replicated data, directly or indirectly, from the designated primary member

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

Также среди кодов событий в логе нужно уделять внимание следующим:

4304 — The DFS Replication service has been repeatedly prevented from replicating a file due to consistent sharing violations encountered on the file. The service failed to stage a file for replication due to a sharing violation.

4412 — The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.

5008 — The DFS Replication service failed to communicate with partner <имя сервера-участника группы> for replication group <имя группы репликации>. This error can occur if the host is unreachable, or if the DFS Replication service is not running on the server.

5014 — The DFS Replication service is stopping communication with partner <имя сервера-участника группы> for replication group <имя группы репликации> due to an error. The service will retry the connection periodically.

Все эти события не должны быть массовыми, 4304 и 4412 говорят о конфликтах записи файлов, поэтому их надо разбирать подробнее в каждом случае. А если случаются 5008 и 5014, они должны сменяться успешными подключениями, например:

5004 — The DFS Replication service successfully established an inbound connection with partner <имя сервера-участника группы> for replication group <имя группы репликации>.

Почему важно настроить комбо из DFS и бэкапов, и причем тут червь-шифровальщик «Петя»

Итак, в плане выполнения показателя RTO настройки DFS являются «холодным» резервом, так как для переключения потребуется некоторое время на действия сотрудника. Но за счет онлайн-репликации обеспечивается выполнение показателя RPO, то есть значительно сокращаются потери данных при авариях по сравнению с резервированием файлового сервера только на основе бекапов.

И все же для серверов с репликацией на основе DFS недостаточно настроить только одну репликацию, чтобы гарантировать сохранность данных. В плюс к ней необходимы и бэкапы, желательно с несколькими точками восстановления по датам.

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

Следуйте советам из этой статьи, резервируйте данные и спите спокойно. Желаем всем безотказной работы!

Сохранить, нельзя потерять, или почему нужно резервировать сервисы всеми доступными способами