Средство достижения наилучшей производительности базы данных и эффективного резервирования
Одна из многих задач администратора базы данных состоит в управлении базами на SQL Server в условиях постоянно растущих потребностей в отношении хранения данных. Как часто придется добавлять новые диски? Нужно точно определить размер базы данных? Требуется более эффективно использовать существующий объем диска? Если хранить базу данных на системе SAN, можно облегчить решение этих вопросов, улучшить производительность дисков и повысить отказоустойчивость базы данных, сократить время резервного копирования и время восстановления. Чтобы хранить данные в SQL Server, следует изучить основы технологии SAN и преимущества ее использования. Во врезке «Выбор массива хранения для SAN» описывается несколько особенностей, которые следует учитывать при выборе массива хранения для SAN.
Основные принципы SAN
Основу SAN составляют сетевые коммутаторы, которые подключают серверы к массивам хранения данных. Топология SAN подобна той, по которой связываются коммутаторы Ethernet, как показано на рисунке. На физическом уровне SAN включает сеть из оптоволоконных каналов Fibre Channel или коммутаторов Ethernet. Оптоволоконные коммутаторы подключены к адаптерам HBA и в массиве хранения, и на сервере. Коммутаторы Ethernet соединяются с сетевым адаптером Ethernet на сервере и в массиве хранения.
|
| Рисунок. Топология SAN |
Массив хранения — это внешняя дисковая подсистема, которая обеспечивает внешнее хранилище для одного или более серверов. Диапазон цен и возможностей массивов хранения широк. На нижнем уровне массив состоит просто из группы дисков в одном корпусе, связанном физически или кабелем SCSI либо волоконно-оптическим каналом с арбитражной логикой (FC-AL). Этот тип простого универсального массива также имеет общее название Just a Bunch of Disks (JBOD). В массивах высокого уровня производители систем хранения обеспечивают такие свойства, как более высокая отказоустойчивость и производительность, снимки данных, зеркалирование внутри массива и между массивами и возможность выделять для сервера больше памяти, чем физически имеет система хранения.
Существует два типа SAN: Fibre Channel и iSCSI. Fibre Channel SAN требуют на сервере наличия адаптера главной шины (далее HBA), подключенного к оптоволоконному коммутатору. HBA аналогичен адаптеру SCSI, который позволяет серверу соединяться с цепочкой внешних дисков, а также обращаться к этим дискам через протокол SCSI. HBA позволяет серверу обращаться к цепочке дисков SCSI, как и к любому диску на любом массиве хранения, связанному с SAN по SCSI.
iSCSI SAN используют коммутаторы и адаптеры Ethernet для связи между серверами и массивами хранения через протокол iSCSI по сети TCP/IP. Как правило, применяется коммутатор и адаптер Gigabit Ethernet, хотя коммутаторы и адаптеры на 10 Gb Ethernet становятся более популярными в серверной среде Windows.
В системе SAN сервер — это клиент системы хранения, иначе говоря, сервер хранилища. Сервер, который действует как первичный потребитель дискового пространства, называется инициатором, а сервер хранилищ, который предоставляет это дисковое пространство, называется адресатом.
Диски, обеспечивающие хранение в SAN, имеют номера логических устройств LUN и для сервера Windows в сети играют роль локальных жестких дисков. Производители массивов хранения используют разнообразные методы, чтобы представить многочисленные жесткие диски в массиве хранения как локальные и выдавать LUN серверу Windows, который пользуется этими жесткими дисками. Производители для повышения устойчивости к сбоям и производительности также используют различные схемы RAID для доступа к данным по номеру LUN. Применяются SAN-коммутаторы Fibre Channel или Ethernet — в конечном счете все это на сервере Windows в оснастке Microsoft Management Console (MMC) Disk Management выглядит как подключенные напрямую диски, и, по сути, нет никакой разницы, как физически расположены диски на сервере. Кроме того, большинство массивов имеет несколько типов RAID, так что хранилище, которое представляет LUN, распределено по всему множеству жестких дисков, находящихся внутри массива.
Безопасность SAN
Архитектура SAN предусматривает две ступени для безопасного доступа по LUN к SAN. Первая ступень реализована в коммутаторе и называется зоной. Зона аналогична виртуальной локальной сети (или VLAN); она ограничивает доступ предоставлением прав только ограниченному числу портов на некоторых хостах, имеющих доступ к нескольким, но не ко всем массивам хранения в SAN.
Вторая ступень определяется массивом хранения; массив для ограничения доступа может использовать маскирование LUN. В зависимости от производителя, эта особенность защиты либо поставляется бесплатно с массивом, либо оплачивается отдельно как лицензируемый продукт. Маскировка LUN может быть настроена либо администратором, либо продавцом массива за отдельную плату. Когда маскирование реализовано, массив предоставляет права только явно заданным портам на явно названных хостах, показывая путь доступа к указанному LUN. Функции маскирования LUN доступны для совместного использования в среде Windows, подобно списку контроля доступа общего ресурса Common Internet File System (CIFS).
Преимущества использования SAN
Теперь, когда мы выяснили, что такое SAN, можно рассказать о том, какие преимущества SAN могут принести пользователям SQL Server. Но прежде чем затронуть этот вопрос, мы исследуем проблемы, свойственные серверу с дисками, подключенными напрямую, Direct Access Storage (DAS), а затем рассмотрим, как использование SAN помогает избежать этих проблем.
Производительность и надежность. При проектировании базы данных, которая должна размещаться на локальном диске (или DAS), администратор определяет, какие из дисков, на которых база данных будет сохранена, связаны друг с другом (т. е. какой из дисков к какому адаптеру SCSI подключен). Администратор должен тщательно организовать файлы базы данных, чтобы минимизировать конфликты между претендентами на дисковые ресурсы, например между таблицей и индексами на таблицу, между двумя таблицами, которые часто связываются между собой, или между данными и журнальными файлами. Чтобы минимизировать конкуренцию (т. е. сократить число операций ввода/вывода), требуется разнести два конкурирующих объекта, причем не только на разные диски, но и на разные адаптеры SCSI.
Другая связанная с диском проблема, которую необходимо рассмотреть при проектировании базы данных, — надежность. Чтобы защититься от дисковых сбоев, приходится использовать несколько типов дисковых массивов с избыточностью. Как правило, применяется либо тип RAID1 (зеркалирование), либо RAID 5, что обеспечивает избыточность и таким образом повышает надежность.
После того как с помощью Windows Disk Management создан RAID, можно разместить базу данных, распределяя ее на нескольких устройствах хранения в RAID. При размещении таких устройств необходимо решить, какие установить размеры. При определении размера хранилища для каждого сервера требуется умение прогнозировать. Переоценка или недооценка потребностей в хранении данных в любом случае наказуема. Если потребности в хранении переоценены и приобретено слишком много дисковой памяти, получается, что за хранение данных переплачено. Если потребности в хранении недооценены, то скоро придется искать способы устранения дефицита ресурсов.
SAN берется решить вопросы конфликтов, надежности и емкости. На SAN массив хранения обычно объединяет пул дисков и создает LUN для всех дисков, находящихся в пуле. Различные диски пула могут быть подключены к различным адаптерам массива так, чтобы входящий и исходящий трафик пула автоматически рассредоточивался. Поскольку массив хранения распределяет LUN по всем дискам и адаптерам, присоединенный к SAN сервер Windows видит его в Disk Management как один диск. Пользователю как раз требуется видеть хранилище как один диск, и его не должна беспокоить производительность и надежность конкретного диска; он полагает, что администратор хранилища или сетевой администратор должным образом сконфигурировали SAN.
Каким быть массиву хранения, сложным или простым, зависит от производителя. Я рекомендую встретиться со специалистом, ответственным за настройку хранилища, и попросить его объяснить вашу структуру массива хранения. Кроме того, следует заранее определить свои требования к хранению и передать их этому сотруднику. Дополнительно к размеру хранилища обратите внимание на требования к производительности (например, пиковая производительность — 40 Мбит в секунду); надежность (например, 99,999 %); резервирование и восстановление (например, почасовые резервные снимки занимают одну минуту, восстановление — 10 минут). Также важную роль играет восстановление после сбоя, основанное на метриках реального времени восстановления — времени, которое требуется, чтобы вернуть базу данных в рабочее состояние после сбоя, и реального времени восстановления после обнаружения ошибки — насколько устарели данные, которые используются при восстановлении. Эти параметры помогут администратору системы хранения лучше понять ваши требования к хранению данных.
Некоторые производители массивов хранения позволяют динамически расширять LUN, который создан в рамках дискового пула, не заставляя простаивать SQL Server, чьи файлы принадлежат этому LUN. Такая возможность позволяет администратору базы данных оценивать свои требования к дисковому пространству более предусмотрительно и добавлять память, не останавливая работы сервера.
Управление резервным копированием. По мере роста базы данных требуется все больше времени, которое необходимо для выполнения ее резервированного копирования. В свою очередь, более долгое резервирование требует большего технологического перерыва. Частичные резервирования вроде резервирования журналов изменений базы данных занимают меньше времени, но требуется больше времени, чтобы из этих журналов можно было восстановить данные. А дальше — больше, начальство требует сократить технологические окна для резервирования и ускорить восстановление для основных приложений, многие из которых работают с SQL Server. Использование SAN может помочь сократить время технологического перерыва для резервного копирования и время, затрачиваемое на восстановление. Некоторые массивы хранения могут непрерывно записывать снимки базы данных (т. е. копии данных на определенный момент), которые ускоряют резервирование и восстановление по сравнению с традиционными методами резервирования баз данных. Снимок не содержит никаких реально существующих скопированных данных. Вместо этого он содержит копии указателей на оригинальные данные на тот момент, когда снимок выполнялся. Дополнительную информацию о возможностях снимка можно найти в статье «Что нового в SQL Server 2005 для DBA?», опубликованной в Windows IT Pro/RE № 8 за 2005 г.
Чтобы выполнять резервирование данных SQL Server, используя снимки, базу данных обычно переводят на несколько мгновений в состояние готовности к резервированию, чаще называемое состоянием горячего резервирования, для выполнения снимка. Если не переводить базу данных в состояние горячего резервирования, снимок может содержать копию данных на тот момент времени, когда SQL Server еще не закончил выполнять последовательную запись в базу данных. Производители массивов памяти, чтобы дать возможность их программному обеспечению переводить базу данных в состояние горячего резервирования, часто используют SQL Server Virtual Backup Device Interface API. Этот API позволяет системе копировать образ моментального снимка на отдельное устройство резервирования без перерыва в работе.
Использование снимков доставляет минимум хлопот, так что их можно применять без потери производительности в работе базы данных. Восстановление данных из снимка занимает всего несколько секунд. Использование массива хранения SAN с возможностями снимков позволяет администратору базы данных минимизировать технологический перерыв для резервирования и время восстановления, отчасти потому, что образы снимков распределены не по одному диску, а по всему дисковому массиву.
Уменьшение рисков при модификации базы данных. Процедуры изменения базы данных, такие как обновления SQL Server или прикладных приложений, либо процедуры развертывания программных исправлений могут быть сопряжены с определенным риском, особенно если эти изменения вызывают остановку в работе базы данных или даже ее разрушение. Чтобы проверить изменения, прежде чем реализовать их на промышленной базе данных, на предмет возможного риска, нужно где-то в другом месте установить базу данных, эквивалентную по размеру промышленной. На этом свободном хранилище необходимо восстановить недавнюю резервную копию базы данных. Администратор потратит несколько часов (возможно, даже дней) на восстановление базы данных с ленты на диск, после чего потребуется еще применять изменения, а затем и тестировать. Затем надо проверить, успешно ли применилось изменение и были ли неблагоприятные воздействия на базу данных. И только после того, как все проверено и изменения успешно осуществлены, можно внедрять их в промышленную базу данных.
Некоторые поставщики массивов памяти SAN позволяют быстро клонировать базы данных для целей тестирования. Клонирование данных занимает всего несколько секунд, тогда как восстановление базы данных с ленты выполняется несколько часов. Дополнительная выгода от клонирования заключается в уменьшении времени использования диска. Некоторые технологии клонирования позволяют задействовать снимок базы данных только для чтения и преобразовывать его в клон с возможностью записи. При тестировании клон потребляет гораздо меньше дисковых ресурсов, чем полная резервная копия базы данных, потому что в клон копируются только измененные блоки данных.
Когда имеет смысл использование дисковой памяти DAS?
Хранение базы данных в SAN предоставляет возможности, недоступные в DAS, такие как локальное и удаленное зеркалирование, клонирование данных, способность совместно использовать данные на многих хостах и возможность делать снимки данных. Однако, если в этих возможностях необходимости нет, хранение базы данных SQL Server на массивах DAS может иметь большой смысл. Окружение SAN состоит из многочисленных клиентов SAN с несколькими адаптерами на коммутаторах SAN, связанными с массивами хранения. Если система SAN не была должным образом приспособлена и настроена (для обеспечения избыточности), массив хранения или любой компонент SAN может дать сбой, и тогда серверы, использующие SAN, не cмогут обращаться к данным, размещенным на массивах памяти.
Занимаясь решением проблем хранения, необходимо удостовериться, что в SQL Server двоичные файлы и файлы журналов сохраняются на локальном диске. Хранение этих файлов на диске, отличном от локального, ставит базу данных в ситуацию замкнутого круга, когда отказ при доступе к базе данных, вызванный отказом соединения с хранилищем, не может быть зарегистрирован в журнале, потому что регистрация происходит только на устройстве, на котором хранятся двоичные файлы и файлы журналов.
Как начать использовать SAN
Если у организации еще нет сетевой среды Fibre Channel SAN, применение iSCSI, вероятно, даст больший коэффициент окупаемости инвестиций и минимизирует вложение средств в оборудование. Для Fibre Channel SAN необходимо приобрести массив хранения, коммутаторы Fibre Channel SAN и адаптеры. Для iSCSI SAN нужно покупать массив хранения, но можно использовать и имеющиеся коммутаторы Ethernet и адаптеры Gigabit Ethernet. Чтобы включить имеющиеся серверы Windows в iSCSI SAN, требуется только загрузить для используемой версии операционной системы и установить драйвер iSCSI. Можно загрузить последнюю версию iSCSI драйвера компании Microsoft iSCSI Software Initiator по адресу http://www.microsoft.com/downloads/ details.aspx?Familyid=12cb3c1a-15d6-4585-b385-befd1319f825*displaylang=en. Процедура настройки массива и подключения его к серверам Windows может оказаться сложной. Это зависит от производителя системы хранения. Как уже упоминалось выше, нужно определить требования к массиву хранения.
Современные массивы хранения позволяют обращаться к LUN на одном и том же массиве и по Fibre Channel, и по iSCSI. Я обнаружил, что многие ИT-окружения не используют все преимущества свойств SAN. Если в организации уже используется сетевой коммутатор Fibre Channel SAN, можно опробовать некоторые функции хранилища, вроде клонирования и снимков, в тестовой среде. Если организация еще не обзавелась SAN, можно протестировать некоторые возможности относительно недорого хранилища iSCSI SAN.
Как мы могли убедиться, размещение базы данных на SAN может принести пользу администраторам баз данных. SAN помогает решить многие проблемы при постоянно растущих требованиях к хранению базы данных, увеличить суммарную производительность системы хранения, упростить настройку и повысить надежность. Кроме того, использование SAN может сократить время процедуры резервирования и восстановления. Также упростится процесс тестирования. Есть один фактор, который до сих пор не позволял некоторым пользователям исследовать SAN, — это высокая цена. Наличие iSCSI устраняет его. Настало время испробовать технологию SAN и посмотреть, способна ли она улучшить систему хранения базы данных.
Мел Шам - Системный архитектор компании Network Appliance из Калифорнии, специализируется на интеграции бизнес-приложений и баз данных с многофункциональными системами хранения. mel.shum@netapp.com
Выбор массива хранения для SAN
Массивы хранения предлагаются в широком диапазоне производительности и возможностей, и выбор сделать нелегко. Рекомендации этой статьи могут помочь подобрать нужный тип массива хранения и построить свою базу данных SQL Server.
Методологии cнимка. Снимки работают одинаково на всех массивах хранения. Идея состоит в замораживании всех блоков с данными в базе данных и структуре данных, захваченных в определенный момент времени. Продавцы используют одну из двух основных методологий обработки снимков после того, как данные были изменены. Первый метод показан на рис. А и состоит в использовании свободного блока для записи модифицированной информации блока. Из двух подходов этот более эффективен, потому что подразумевает только одну операцию ввода/вывода блока для записи в новый блок и одно изменение указателя.
Второй метод состоит в копировании блока снимка в свободный блок и последующем переписывании блока, который только что был скопирован. Этот метод, показанный на рис. Б, часто называют копированием при записи. Метод copy-on-write требует перемещения большего количества данных и больших накладных расходов в части массива хранения по сравнению с первым. На рис. Б блок D перемещен из текущего блока в новый блок так, чтобы новое содержание D могло быть переписано в прежнее местоположение блока D. Такая процедура требует трех операций ввода/вывода блоков и модификации ссылки, тогда как первый метод требует только одной операции ввода/вывода блока. Это расхождение сильно сказывается на производительности диска, если модифицируется большое количество блоков.
Поддержка для Fibre Channel и iSCSI на одних и тех же массивах. Имеет смысл рассмотреть вопрос приобретения массива хранения, который поддерживает и Fibre Channel и iSCSI. Тогда можно легко переключаться от одного к другому или использовать оба. Например, можно задействовать iSCSI SAN для тестирования и развертывания, а Fibre Channel SAN — для промышленного использования.
Способность динамически создавать, добавлять и удалять LUN. Возможность создавать, добавлять и удалять LUN, не прерывая работу базы данных, — главное преимущество размещения базы данных на SAN. Если есть необходимость в такой возможности, обратите внимание на массивы хранения, которые ее предоставляют.
Интеграция резервного снимка с SQL Server. Процесс получения снимка базы SQL Server должен быть скоординирован с базой данных и файловой системой NTFS. Производители массива памяти могут использовать SQL Server VDI API, чтобы осуществить такую координацию. Когда процесс создания снимка не синхронизирован с файловой системой NTFS и базой данных, создание снимка не может происходить в последовательном режиме, потому что либо NTFS, либо база данных не может полностью сбросить задержанные данные для записи из памяти в LUN.
Универсальная операционная система хранилища. Для целей тестирования и проверки преимуществ, а также перед тем, как внедрять продукт в промышленную эксплуатацию, лучше начать с небольшого массива SAN. Найдите массив хранения, который позволяет расти без того, чтобы обязательно выполнять полную замену или без необходимости изучать операционную систему нового хранилища. По мере роста потребностей поддержка совместимости позволяет модернизировать массив хранения с минимальным временем простоя базы данных.
Транспортный механизм к данным через глобальную сеть к узлу восстановления. Массив хранения должен предусматривать унифицированный транспортный метод для пересылки отображенных данных через глобальную сеть к другому массиву хранения с целью восстановления после сбоя.
Способность незамедлительно создавать перезаписываемую копию базы данных. Обратите внимание на массивы хранения, которые позволяют незамедлительно создавать перезаписываемую копию (т. е. аналог) базы данных для испытания обновлений и большего количества загрузок данных без необходимости задействовать для тестирования промышленную базу данных. Эта возможность может уменьшить время простоя и устранить разрушение промышленной базы данных, а администратор базы данных получит инструмент для проверки важных изменений без угрозы потери ценной информации.