Жизненно важно определить ключевые требования к приобретаемому приложению, хранящему свои данные на сервере SQL Server (да и в любой системе управления реляционными базами данных), чтобы обеспечить необходимый уровень безопасности, доступности ресурсов и других критических показателей архитектуры перед началом развертывания. В это время изменения еще не влияют на работу конечного пользователя. Перед тем как будет развернуто оборудование или установлено программное обеспечение, необходимо получить ответы на 17 ключевых вопросов.
За 15 лет работы в качестве администратора баз данных и консультанта по работе с данными я выработал определенный подход. Он заключается в составлении формализованного опросника, включающего все вопросы, ответы на которые необходимы мне для того, чтобы «принять на борт» новый экземпляр базы данных SQL Server. Перенимать право собственности на приобретенные решения всегда сложнее, чем на разработанные самостоятельно, ведь такие решения создавались для широкого круга клиентов, без знания вашей среды и ее особенностей. Поэтому еще более важно заранее получить всю необходимую информацию — до того, как будет установлен хоть один сервер или принято решение о предоставлении хостинга. Это позволит убедиться в том, что вы строите окружение, подходящее для хостинга базы данных. Избыточное проектирование оказывается пустой тратой ресурсов и может привести к тому, что вы будете поддерживать выделенный экземпляр SQL Server, который никогда не потребуется. Некачественное проектирование решения приводит к появлению уязвимых мест, которые могут давать о себе знать на протяжении всего срока службы приложения.
Вот «горячая двадцатка» вопросов, которые я задаю, когда дело доходит до принятия на обслуживание базы данных при интеграции нового решения на основе SQL Server.
1. Контактная информация технического специалиста со стороны поставщика оборудования.
Если ночью что-то пойдет не так, я должен убедиться, что у клиента есть решение на случай, если проблема будет не на уровне базы данных, а, следовательно, не попадет в мою зону ответственности. Кроме того, если я сталкиваюсь с проблемой, связанной с производительностью или структурой, и требуется участие разработчика или специалиста технической поддержки, мне опять-таки понадобится эта информация.
2. Каковы внутренний уровень поддержки, уровень обслуживания, ожидаемое время работы, период восстановления для данного приложения?
Мне необходимо знать, чего ожидают от этого приложения конечные пользователи и мои клиенты, чтобы разработать соответствующий план хостинга. Ответы на эти вопросы позволяют мне принимать решения относительно платформы хранения, механизмов высокой доступности для системы SQL Server, а также средств виртуализации и, возможно, внедрения технологий, таких как Site Recovery Manager, если они поддерживаются в том окружении, в котором я работаю при решении конкретной задачи.
3. Есть ли необходимость в использовании возможностей корпоративной редакции SQL Server?
Некоторые механизмы существуют только в редакции Enterprise Edition, и перечень соответствующих функций от версии к версии меняется. Более того, в младших редакциях SQL Server предусмотрены ограничения по ресурсам, которые могут сыграть свою роль в зависимости от тех требований, которые предъявляет развертываемый продукт. Например, если вы установите систему SQL Server Standard Edition на предполагаемом сервере, то не сможете в полной мере использовать 256 Гбайт оперативной памяти, так как для данной редакции существует ограничение в 128 Гбайт оперативной памяти (на сегодня). В конечном счете мне нужно знать, можно ли развертывать младшую редакцию SQL Server или нельзя обойтись без установки редакции Enterprise Edition. В зависимости от соглашений Software Assurance у той организации, в которой я работаю, данное начинание может быть не очень дорогостоящим. Если я работаю с выделенным под задачи SQL Server кластером VMware, в котором лицензия SQL Enterprise Edition приобретается на физические хосты, то фактически могу использовать столько корпоративных виртуальных машин, сколько понадобится, до тех пор пока лицензии на ядра не будут израсходованы. В этом случае лицензирование инфраструктуры SQL Server Enterprise имеет фиксированную стоимость для организации, и эти лицензии просто ожидают своего часа.
4. Какие поддерживаются версии Microsoft SQL Server?
Если мы говорим о редакциях SQL Server, то стоит упомянуть и о версиях SQL Server. Например, в Америке многие из прикладных решений для задач здравоохранения (если не большинство) жестко привязаны к версиям SQL 2008 или 2008 R2 в силу законодательных требований. Важно понять, какая версия SQL Server поддерживается, и не менее важно, чтобы наборы функций этой версии поддерживались, несмотря на ограничения, накладываемые механизмами высокой доступности или редакцией, для определенной комбинации версии и редакции.
5. Поддерживается ли виртуализация?
Удивительно, что на этот вопрос еще случается слышать ответ «нет». Иногда для компании, разрабатывающей приложение, можно предложить возможность обучения и повлиять на мнение руководства. Хотя это не всегда удается. В некоторых случаях виртуализация не является оптимальным выбором, но я хочу знать, есть ли у меня, по крайней мере, возможность использовать ее, если решение мне подходит.
6. Нужно ли включить в окончательную архитектуру другие ориентированные на SQL Server продукты?
Требуются ли для реализации проекта продукты SSAS, SSIS, SSRS, Change Data Capture (CDC), Auditing, Replication, Full Text Search, CLR или Filestream? Если да, то я хочу знать об этом заранее. Допустим, вся информация, которую я собрал, будет говорить о том, что база данных может быть размещена на совместно используемом экземпляре SQL Server. После этого я узнаю, что данной базе требуется локальная установка службы SSIS из-за ограничений в процессе разработки, и я должен либо изменить существующий совместно используемый экземпляр либо предоставить новый сервер. Я хочу определить для себя полный перечень компонентов, необходимых на локальном сервере SQL Server, а также понять, требуется ли использовать любой из этих продуктов на других узлах центра обработки данных.
7. Существуют ли аспекты, связанные с безопасностью, которые не позволят успешно задействовать данное решение на совместно используемом экземпляре SQL Server?
При выборе схемы размещения ресурса — совместно используемые или выделенные экземпляры SQL — роль вопросов безопасности весьма велика. Как правило, чтобы определить границы установки, я задаю все без исключения вопросы, касающиеся безопасности, приведенные ниже:
- Распределение — могут ли компоненты приложений быть отделены от слоя базы данных и зависит ли данный факт от того, установлены ли приложение и база данных на одном сервере?
- Требования к эксклюзивности — может ли база данных рассматриваемого решения быть размещена на общем или объединенном экземпляре SQL Server?
- Учетные записи и пользователи — какие роли сервера необходимо предоставить для конечных пользователей и сотрудников службы технической поддержки разработчика? Если к ролям сервера предъявляются какие-либо требования, я делаю вывод, что для решения необходим выделенный экземпляр SQL Server. Я не хочу, чтобы любой пользователь базы данных X имел возможность влиять на базу данных Y (за исключением влияния через потребление ресурсов, управлять которым можно с помощью инструмента Resource Governor). Кроме того, мне важно знать, какие права должны быть предоставлены пользователям в базах данных. В конечном счете, я хочу следовать модели наименьших привилегий и предоставлять только необходимый минимум прав. Максимум, на что я готов пойти — это предоставить права db_datareader, db_datawriter, а также право на исполнение, всем хранимым процедурам и функциям, которым это необходимо. Я всегда буду против назначения ролей DBO или db_owner, так как эти роли позволяют выполнять задачи, которые теоретически могут сделать экземпляр SQL Server недоступным для всех.
8. В базе данных хранятся или обрабатываются конфиденциальные данные?
Сведения о здоровье пациента, кредитная или финансовая информация, данные о зарплате, номера социального страхования — это ценные данные, и в надежде получить их «стены» ваших межсетевых экранов осаждают «орды варваров». В зависимости от типа данных, вашего географического положения и сферы деятельности существуют стандарты для хранения конфиденциальной информации, и эти стандарты влияют на то, как осуществляется защита и хранение данных. Кроме того, при работе в физических и виртуальных средах используются различные уровни предъявляемых требований. Ответ на этот вопрос влияет на то, как и где хранятся ваши данные, используется ли шифрование и даже (в тех случаях, когда приложение просто время от времени обрабатывает данные) на то, хранятся ли данные в базе данных SQL или нет.
9. Будут ли настроены интерфейсы к другим системам?
Если ответ на этот вопрос «да», то мне важно знать, какие процессы используются для решения этой задачи: ETL, HL7, API. Кроме того, предполагаем ли мы создавать пакеты SSIS для взаимодействия этих систем? Будет ли предоставлен код, необходимый для построения этих «мостов»? Какие требования безопасности предъявляются к данным процессам? Эти и многие другие вопросы поднимаются, когда необходимо заставить системы взаимодействовать друг с другом.
10. Какие требования к ресурсам процессора для экземпляра базы данных предъявляет разработчик?
Когда приходит время взглянуть на рекомендации разработчика по выделению ресурсов, я уже настроен скептически. Когда я спрашиваю о ресурсах процессора, я также хочу знать, для какого набора микросхем выработаны рекомендации, ведь разработчик может заявить, что нужно выделить 4 процессора, но это утверждение основано на исследованиях, проведенных четыре версии продукта назад для микросхемы Core i5 Lynnfield, а у моего клиента окружение стандартизовано под использование микросхем Core i7 Sandy Bridge. Я должен уметь видоизменять требования разработчиков под возможности именно того микропроцессора, который будет использоваться. Не нужно отталкиваться от устаревших спецификаций, это может привести к избыточному или недостаточному выделению ресурсов процессора. Избыточное выделение ресурсов несет вдвое большие риски, когда для системы SQL Server рассматривается лицензирование «по ядрам». Еще мне важно знать, включает ли заявленное значение запас под работу механизмов CDC или сжатия, если они применяются.
11. Какие требования предъявляются к оперативной памяти для используемого экземпляра базы данных?
Мне нужно знать, какой объем оперативной памяти для данного продукта требует выделить разработчик и включает ли данное значение запас, необходимый для работы приложения, если оно должно быть установлено на одном сервере с базами данных. Если используются службы SSAS, SSIS и прочие вспомогательные решения, то этот вопрос касается и их.
12. Какое ожидаемое и необходимое количество операций ввода-вывода в секунду требуется, чтобы приложение и база данных поддерживали определенную частоту операций чтения-записи?
Я не хочу отвечать на звонки посреди ночи из-за того, что «база данных работает медленно». Является ли эта база данных «крупным игроком» с точки зрения требований к количеству операций ввода-вывода в секунду? Если это так, то у нас есть решения, которые можно применить заранее, на этапе проектирования архитектуры. Такие аппаратные решения, как одноуровневые хранилища, изобретательные стратегии использования RAID, выделенные тома LUN и твердотельные накопители, легче реализовать до ввода в эксплуатацию. Еще одно решение — разделение операций ввода-вывода по различным файлам и группам файлов. Если поддерживается сжатие, оно также может помочь справиться с нагрузкой операций ввода-вывода. Обо всем этом мы должны знать до ввода продукта в эксплуатацию, чтобы не столкнуться с проблемами в процессе использования.
13. Какой объем хранилища необходимо выделить?
По сути, мне нужно получить подробную информацию по следующим вопросам:
- Размер исходных файлов и прогнозируемый ежегодный прирост, исходя из планируемого использования, которое было (я надеюсь) одной из тем обсуждения с менеджером проекта.
- Тот же вопрос, но в отношении журнала транзакций для каждой базы данных.
- В каком объеме планируется использовать базу TempDb в данном решении?
- Планируется ли выгрузка страниц в файл подкачки? Надеюсь, что нет.
14. Требуется ли интеграция каких-либо настраиваемых сценариев SQL Server Agent?
Ответ на этот вопрос повлияет на принятие решений в области безопасности - разрешать ли назначение пользовательских прав на базу данных MSDB. Он также может повлиять на производительность и нагрузку, и хотелось бы как следует рассмотреть соответствующий код, а также провести его аудит и убедиться, что сценарий не пытается выйти за границы баз данных, установленные для этого решения.
15. Есть ли потребность в использовании нестандартной сортировки?
Настройки сортировки определяют кодовую страницу, которая используется для хранения данных, не поддерживающих Юникод, на сервере SQL Server, и то, каким образом сервер SQL Server сортирует и сравнивает символы, хранящиеся в типах данных, не поддерживающих Юникод. Региональные настройки также играют свою роль при настройке параметров сортировки. В случаях, когда база данных может иметь сортировку, отличную от базы данных master, лучше всего с самого начала настроить базу данных на использование правильной сортировки, прописанной в требованиях. В 9 случаях из 10 сортировка базы данных, скорее всего, будет соответствовать сортировке, задаваемой по умолчанию, но вы должны знать об этом заранее, чтобы избежать возможного перестроения базы в случае выявления факта несоответствия.
16. Каким должно быть окружение для этого решения?
Предполагается, что мы должны построить и поддерживать производственную среду, но как же быть с тестовой средой, демонстрационной средой, сайтом вопросов и ответов, средой для разработки и т.д.? Кроме того, вопрос в том, необходимо ли поддерживать эти среды постоянно или они должны быть уничтожены после ввода решения в эксплуатацию? Каждое окружение должно быть включено в смету ресурсов, и при этом оно подразумевает затраты на серверы, системы хранения, лицензии и время администратора, необходимое для развертывания окружения.
17. Каковы ожидания от аварийного восстановления?
Должны ли мы выполнять резервное копирование каждого окружения? По производственному окружению вопросов нет, но как насчет остальных? Я бы также предположил, что стоит выбрать режим Full Recovery, чтобы обеспечить возможность восстановления на определенный момент времени, но, возможно, данные загружаются только один раз в день и в дальнейшем не изменяются? В таком случае подойдет режим Simple Recovery. Обычно предполагается, что за стратегию восстановления отвечает администратор баз данных, а резервные копии критически важны для восстановления. Понимание требований является ключевым моментом.
Как всегда, ответы на одни вопросы влекут за собой другие, но вопросы, предложенные мной, исключительно важны в начале обсуждения. Я использую их каждый раз, когда сталкиваюсь с новым проектом, в котором участвует система SQL Server.