В статьях, посвященных техническим вопросам, обычно описываются новые возможности имеющихся продуктов или озвучивается некая проблема и предлагается ее решение. Статья, которую вы читаете сейчас, совсем другого рода.
С вашего позволения, я расскажу вам одну историю, которая вполне могла иметь весьма печальный конец. Дело могло кончиться крахом целой компании, что стало бы главной темой новостей в течение нескольких дней. Наконец, это история о понимании — понимании сути технологий, реализацией которых вы занимаетесь, о понимании требований ваших клиентов, понимании важности повышения квалификации персонала, а также о том, на каком этапе следует заниматься профессиональной подготовкой сотрудников.
Подобно многим историям, памятным нам с детских лет, мой сегодняшний рассказ должен начинаться с тех магических слов, которые мгновенно переносят нас в другую реальность.
Итак, в незапамятные времена в тридевятом царстве… я сотрудничал с корпорацией, которая как раз переходила на платформу «облачных» служб Amazon Web Services (AWS). Ее сотрудники создали порядка дюжины систем EC2 (Elastic Compute Cloud — служба, предоставляющая изменяемую вычислительную мощность в «облаке»). Эти системы я должен был объединить в кластеры, установить на них Microsoft SQL Server с дополнениями, а также создать топологию групп доступности для обеспечения высокой степени готовности. Эта среда предназначалась для размещения данных по финансам и кредитам, касающихся всех подразделений компании. Было чрезвычайно важно обеспечить защиту упомянутых данных не только от угроз взлома системы безопасности, но и от всех рисков, а также любого ущерба, угрожающего самому их существованию.
Возможно, кому-то покажется, что в последнем предложении я несколько сгустил краски, однако скоро вы убедитесь, что избранный сотрудниками корпорации способ построения виртуальных машин AWS вполне мог бы привести именно к таким последствиям.
Виртуальные машины, составляющие EC2, могут разворачиваться очень быстро и создаются с одним дисковым томом для запуска. Скорее всего, вы уже знаете, что такой комплект не подходит для сервера баз данных, от бесперебойной работы которого зависит выполнение важного задания (и более того, вся дальнейшая судьба компании). Мои клиенты были достаточно квалифицированными специалистами, чтобы понимать все это, и они, по крайней мере, запаслись дополнительным томом для каждого экземпляра EC2. Именно здесь они намеревались хранить все файлы баз данных SQL Server — системные и пользовательские, все журнальные файлы и резервные копии. В перспективе они планировали оснастить свое решение средствами хранения данных типа S3 и Glacier, что позволило бы хранить резервные копии и архивы на резервных устройствах, но сначала предполагалось размещать будущие данные и резервные копии именно на этих экземплярах EC2. Обычно я храню данные, журналы, системные базы данных, временную базу данных и резервные копии раздельно, и ничем из перечисленного выше не располагаю на том же томе, где размещаются операционная система и страничные файлы. Но среда, в которой мне предстояло работать, была создана моими заказчиками.
Я принялся за дело: начал устанавливать систему Microsoft SQL Server, создавать кластеры и группы доступности, а также очищенные копии данных компании, которые предстояло использовать в качестве заполнителей в процессе создания решения на основе групп доступности. В ходе тестирования отказоустойчивости мы получили неплохие результаты, и было объявлено о нашей готовности к миграции через три дня.
На данном этапе возникла необходимость внести в один из экземпляров SQL EC2 небольшие изменения. Речь идет об экземпляре, который использовался различными базами данных для контроля функционирования инструментальных средств независимых поставщиков, также входивших в состав платформы AWS. Для решения этой задачи инженерам, обслуживающим сервер, нужно было клонировать сервер EC2 и отключить экземпляр EC2 на панели мониторинга AWS. В качестве меры предосторожности я снял резервные копии со всех баз данных и временно разместил их на другом экземпляре SQL EC2, а затем деактивировал службу SQL и отключил ее. Так вот, когда сервер был вновь запущен, система SQL Server не стартовала. Конечно, это странно, но мне уже доводилось сталкиваться с подобными ситуациями. К тому же умение спокойно и рационально подходить к анализу необъяснимых сбоев — обязательное качество для хорошего администратора баз данных. Просматривая журналы регистрации событий, я пришел к выводу, который не приходил мне в голову на протяжении всех 20 лет, что я работал с данными. Когда я взглянул на содержимое экрана Windows Explorer, мои опасения подтвердились. В экземпляре EC2 был представлен всего один накопитель, причем не тот, на котором размещались данные SQL, журналы и резервные копии.
Возможно, у вас возникнет вопрос: почему выключение виртуальной машины влечет за собой исчезновение присоединенного тома? Не говоря уже о том, что речь здесь идет о томе, который был предназначен для хранения критически важных данных и за который уплачены немалые деньги. Чтобы ответить на этот вопрос, вы должны знать, какие решения предлагаются для хранения данных в AWS.
Пользователям обеих платформ, как AWS, так и Azure, предоставляется широкий выбор средств для хранения данных. Эта статья могла быть посвящена любой из двух упомянутых «облачных» платформ. Но поскольку описываемые события разворачивались вокруг платформы AWS, я решил ею и ограничиться. Так вот, если говорить об AWS, то к числу запоминающих устройств, допускающих «прямое» подключение к экземпляру EC2, относится Elastic Block Storage (EBS), постоянное локальное устройство хранения данных для Amazon EC2. Оно пользуется популярностью и подходит для обслуживания реляционных баз данных и баз данных типа NoSQL, хранилищ данных, приложений уровня предприятия, систем обработки Больших Данных, а также средств резервного копирования и восстановления данных. Еще один вариант — служба Amazon Simple Storage Service (S3). Эта служба дает возможность создавать «контейнеры», доступ к которым осуществляется с использованием адресов URL. Обращаться к ним можно из любой точки через Интернет; нужно только, чтобы защита желающих получить доступ к «контейнерам» была обеспечена должным образом. Стоит упомянуть также службу хранения данных Amazon Glacier. Она получила широкое распространение как файловая система, используемая в качестве архива или репозитория. Извлечение данных происходит с задержкой от 3 до 5 часов, но плата за использование хранилища исключительно низка. Единственное из всех перечисленных средств хранения, обеспечивающее прямое подключение к базам данных, — это EBS. Существует еще один тип хранилища данных, не указанный на странице с перечнем хранилищ для AWS и предусматривающий прямое подключение к экземплярам EC2. Речь идет об Amazon EC2 Instance Store.
Значение термина Amazon EC2 Instance Store лучше всего объясняется в официальной документации:
«Хранилище экземпляра, instance store, обеспечивает для экземпляра временное хранилище на уровне блоков. Это хранилище размещается на дисках, физически присоединенных к хостирующему компьютеру. Instance store идеально подходит для временного хранения данных, подвергающихся частым изменениям, таких как буферы, кэши, черновые данные и другое содержимое временного хранения, или данных, реплицируемых на несколько экземпляров, таких как пул веб-серверов для балансировки нагрузки».
Увидев слово «временный», вы можете почувствовать, что по спине у вас бегут мурашки. Когда я обнаружил, что присоединенный том для управляющего сервера после отключения исчез, меня охватил ужас при мысли о том, что кто-то может выключить любой из экземпляров SQL Server, с которыми мы работали столько времени, чтобы довести их до запуска. Это несколько недель работы. Единственное утешение состояло в том, что компания еще не перенесла на эти серверы свои данные по финансам в полном объеме.
И что же я сделал для исправления положения? Решение было совсем несложным, учитывая то обстоятельство, что весь том занимали файлы баз данных и резервные копии.
Первый этап состоял в том, чтобы подготовить надлежащий тип устройства для хранения данных, EBS. Эту задачу выполнили обслуживающие серверы инженеры компании-заказчика. Далее я отформатировал новый том и присвоил ему буквенное обозначение T. Нам нужно было высвободить существующий накопитель, и это был накопитель D.
В ходе второго этапа требовалось остановить работу базовой группы доступности. Процесс состоял из двух частей: остановка кластерной роли группы доступности и остановка самого кластера в среде Failover Cluster Manager. Мы выполняли эту работу одновременно на обеих репликах каждой группы доступности, так что поддерживать кластер в рабочем состоянии не было нужды; более того, это могло бы привести к нежелательным последствиям.
На третьем этапе я переключил внимание с кластера и Windows на SQL Server. Пора было приостановить работу служб SQL и перевести их в отключенное состояние. Зачем отключать службы? Это была мера предосторожности на случай непредвиденных осложнений на этапе, когда позднее мы будем перезапускать экземпляр EC2.
Четвертый этап сводился к простой операции копирования всего содержимого накопителя D и переносу его на накопитель Т на корневом уровне. Я хотел, чтобы во всем (кроме буквы накопителя) два тома полностью повторяли друг друга. Пора было приступать к пятому этапу.
Я открыл консоль управления компьютером и затем оснастку управления диском Disk Management, чтобы изменить символ D в буквенном обозначении текущего накопителя на любой другой неиспользуемый символ. Теперь, когда символ D освободился, мы могли изменить буквенное обозначение накопителя с T на D. Не упускайте из виду, что на протяжении всего этого времени службы SQL Server были отключены. Вся стартовая информация указывает на том D, и теперь мы располагаем новым томом D, который идентичен старому, но размещается в хранилище данных, чье содержимое остается без изменений даже в случае отключения экземпляра на уровне панели мониторинга AWS. Накопитель сохраняет свое состояние в случае перезагрузки виртуальной машины пользователем с именем guest, что я проделывал неоднократно в ходе настройки каждого экземпляра EC2.
И вот настало время тестирования. Службы SQL нужно было вновь привести в рабочее состояние из диспетчера SQL Server Configuration Manager. Сначала мы сделали это на основном экземпляре и убедились в том, что базы данных доступны, а в журнале регистрации отсутствуют ошибки. Я быстро повторил все эти процедуры применительно к службам SQL на дополнительном экземпляре. Теперь следовало пройти по этапам нашей работы в обратном направлении. Я занялся службами SQL и перевел их в оперативный режим, затем перевел в рабочий режим кластер и, наконец, кластерный ресурс для группы доступности. Все шло прекрасно, но оставался еще один последний тест: отключение EC2.
Убедившись, что группа доступности функционирует в асинхронном режиме, я поручил обслуживающему серверы инженеру отключить экземпляр с переходом на дополнительный и приостановил службы SQL на дополнительном экземпляре. Этот процесс занимает целых 5-10 минут, но когда все было готово, «старый» накопитель D исчез, а новый накопитель D остался. Я запустил SQL Server, после чего группа доступности обрела работоспособность и синхронизировалась, причем довольно быстро. Весь процесс был повторен на основной реплике после того, как я провел обработку отказа на реплику, на которой мы только что провели тестирование процедуры перезапуска. После этого мы вновь перешли в рабочий режим. Чтобы вернуться в состояние, в котором мы находились, я выполнил еще одну обработку сбоя.
Наконец, мы повторили данный процесс на всех других группах доступности и смогли придерживаться графика. Из этой истории, в ходе которой мы добились успеха и сумели избежать катастрофических последствий, следует извлечь несколько уроков.
Прежде всего, никогда не беритесь за реализацию незнакомой технологии. У сотрудников компании-заказчика не было достаточно полного представления о платформе AWS и о реализованных в ней решениях. Они не проявили должной осмотрительности и не обратились за консультацией по вопросам архитектуры с использованием уже оплаченных компанией каналов поддержки. Более того, заказчик занялся повышением квалификации своих привлеченных к проекту специалистов в сфере технической инфраструктуры, которым поручалось реализовать это решение (а на первых порах и разрабатывать его архитектуру), лишь на том этапе, когда среда была уже построена. Повышение квалификации сотрудников кому-то может показаться делом слишком затратным. Но если корпорация потеряет все свои финансовые данные и утратит возможность выставления счетов на протяжении всего периода восстановления инфраструктуры, что называется, с нуля, дело может обернуться еще более масштабными расходами.
Далее, перед тем как браться за дело, трижды проверьте работу, предварительно порученную другим участникам процесса. На первый взгляд наши накопители казались идентичными. Но если бы исполнители хотя бы полистали технические спецификации или в течение пяти минут последили за панелью мониторинга AWS, проблема была бы выявлена задолго до того, как она была обнаружена на самом деле.
Наконец, действуя в незнакомой обстановке, не бойтесь задавать вопросы и просить о помощи. Никто из нас не является универсальным специалистом. Успех — результат труда всей команды.
Благодаря общим усилиям нам удалось избежать кризиса. Заказчик был доволен, я получил свой гонорар, и, как положено заканчиваться сказкам, «с тех пор жили они долго и счастливо».