Шейла Молнар (smolnar@penton.com)- редактор журнала SQL Server Magazine

.

SQL Server Magazine: Интересно узнать, как в MySpace приняли решение о выборе SQL Server среди других платформ баз данных предприятия?

Хала Эль Адван, вице-президент по данным
Хала Эль Адван, вице-президент по данным

Эль-Адван: Меня постоянно спрашивают: «Почему SQL Server?». MySpace выбрала платформу Windows и SQL Server, потому что этот выбор обеспечивает нас средой быстрой разработки. По сравнению, например, с конкурентами из лагеря открытого кода, SQL Server оказывается проще устанавливать, на нем быстрее запускать/выполнять и удобно разрабатывать. Вот по какой причине решение MySpace было запущено на платформе Microsoft, а именно на SQL Server 2000. Когда мы начинали в 2003 году, у нас был один экземпляр SQL Server, работавший на одном сервере. Все было хорошо, пока мы не начали расти. Нашим первым подходом к масштабированию была модель ведущий/ведомый, использующая репликацию транзакций. Мы копировали ведущий сервер (узел чтения/записи) на все прочие ведомые узлы, и это работало прекрасно, пока мы не достигли уровня более двух миллионов пользователей.

На этой отметке начались трудности с задержками при репликациях. Это вызывало проблемы с данными, предоставляемыми пользователям. Мы все еще оставались с двухъярусной архитектурой: у нас были веб-серверы, напрямую обращавшиеся к базам данных. Это стало ключевым соображением при обсуждении масштабирования.

Мы выбрали подход с вертикальным секционированием и распределили функциональные компоненты по различным серверам; это работало, пока мы не подобрались к уровню в четыре миллиона пользователей. Теперь у пользователей появилась проблема с «множеством серверов»: как скомбинировать серверы, если требуется воспроизвести ощущение индивидуальной работы для каждого пользователя? Мы задались вопросом: «Каков идеальный путь объединения всего, что мы узнали о репликации, о вертикальном секционировании, чтобы построить масштабируемую модель, которая сможет обеспечить представление ‘отдельный пользователь — единственный сервер’?»

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

Решение масштабироваться горизонтально появилось ранее, на уровне двух миллионов пользователей, когда мы решили придерживаться модели, в которой сможем добавлять новые серверы (масштабироваться горизонтально), а не пытаться перенести все на большой сервер. Посмотрим на нашу базу данных пользователей: у нас есть профили конфигурации, у нас есть обмен сообщениями и коммуникация. Мы подразделяем эти функции на группы и в пределах каждой из них делим все на пользовательские диапазоны. То есть у нас имеются отдельные базы данных для каждого миллиона пользователей, и мы открываем новую базу для каждого следующего миллиона. Исходя из этого прикладной уровень переправляет активного пользователя к базе данных, соответствующей его идентификации. Такой, вкратце, была эволюция использования SQL Server в среде MySpace.

Криста Штельцмюллер, главный архитектор данных
Криста Штельцмюллер, главный архитектор данных

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

SQL Server Magazine: Вы начинали с SQL Server 2000, а на какие версии SQL Server переходили за прошедшее время?

Эль-Адван: Сейчас мы работаем с SQL Server 2005 и планируем миграцию на SQL Server 2008 Enterprise Edition.

Штельцмюллер: Сегодня мы в основном используем SQL Server 2005, Standard Edition, однако на наших отказоустойчивых кластерах применяется Enterprise Edition.

SQL Server Magazine: Вы упомянули, что у вас имеется по базе данных на миллион пользователей. Сколько же всего баз данных и серверов используется компанией?

Эль-Адван: Нашу «опору» составляют приблизительно 450 серверов. Если вы сложите базу данных профилей пользователей со всеми другими базами данных, которые необходимы для поддержки различных функций, с базами данных загрузки, а также с базами данных по инфраструктурам обмена сообщениями, то получите более 1200 баз данных. Что касается учетных записей, то наша база данных ежемесячно активных пользователей включает приблизительно 130 миллионов единиц. Также мы имеем порядка 250–270 миллионов учетных записей активных пользователей.

SQL Server Magazine: Вы используете виртуализацию?

Эль-Адван: Наши базы данных не виртуализованы. Мы широко используем виртуализацию в средах разработки и подготовки к эксплуатации. Но пока у нас нет виртуализации в производственной среде.

Я работала с SQL Server многие годы до MySpace, возглавляя направление данных, — многие вопросы, с которыми мы сталкивались в небольших разработках, аналогичны тем, которые встретились нам в MySpace. Мы говорили о нашем масштабе — он действительно весьма велик; однако и на предыдущей моей работе управление обменом сообщениями и целостностью транзакций на нескольких серверах представляли проблему, хотя количество серверов было невелико. Эта же проблема все еще остается у нас с 450 серверами, единым профилем пользователя и управлением целостностью транзакций на всех этих системах. Это сильно беспокоило нас, когда мы перешли к федеративной модели; мы пытались справиться с задачей, организуя, в какой-то мере, дублирование данных, но это не слишком помогало. Мы решили ввести промежуточный прикладной уровень, на котором осуществляли некое элементарное управление транзакциями, особенно для пользовательского уровня, потому что пользователи вовлекали в работу очень многие базы данных. Сегодня у нас есть более подходящее решение, с применением Service Broker в пределах базы данных. Мы пытались обеспечить каждому пользователю ощущение, что он работает отдельно, но для того, чтобы он имел дело с однотипными данными, «живущими» во множестве мест, мы применяли репликацию на SQL Server. Определенные типы данных копировались в такие же в базе данных пользовательских профилей. Это работало неплохо, вплоть до предела в 100 миллионов пользователей. Репликации на SQL Server показывают себя отлично, когда все идет хорошо, но если при таком масштабе случались отказы, то они вызывали каскадный эффект с неприятными последствиями. Мы работали в тесном контакте с командой разработчиков SQL Server и консультировались с ними по нашим проблемам. Они сотрудничали с нами для разрешения многочисленных программных ошибок, которые проявились в работе нашей системы репликации. Мы построили промежуточное решение для диапазона в 100 миллионов пользователей — оно помогало нам обрабатывать загрузку, которой должна была управлять единственная распределяющая база данных; а со временем пришли к решению вообще не основанному на репликациях.

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

В начале работы MySpace подобные проблемы с данными проявляли себя на сайте как ошибки. Большие красные ‘X’ появлялись на том месте, где должны были быть данные. Тогда мы обратились к Service Broker. Я убеждена, что MySpace осуществляет одну из наиболее обширных разработок по Service Broker для SQL Server на сегодня. Мы применяем Service Broker для ведения асинхронного контроля прав в базе данных. Сначала проблемы с масштабом были связаны просто со временем ожидания, ввиду огромного количества подключений к небольшому количеству серверов. Мы ценили Service Broker за то, что он дал нам возможность записывать данные таким образом, что мы могли обработать их постфактум. Он также позволил нам начать сквозное управление транзакциями через все базы данных. Это было критично ввиду распределенности среды. Первоначальная версия Service Broker имела лишь одноадресную рассылку, что было ее большим недостатком: это означало, что физические маршруты следовало вводить между каждой службой и каждой базой данных. Мы говорим об окружении, в котором одна база данных могла обращаться к нескольким сотням баз данных (потенциально) – это создавало проблему обслуживания.

Мы исследовали различные возможности Service Broker, в том числе динамическое управление маршрутами, предназначенное для решения проблем обслуживания, но допускающее лишь одноадресную рассылку сообщений. Этого нам было недостаточно. Мы решили разработать собственный продукт, который назвали Service Dispatcher, для наращивания функциональности Service Broker. Очень важно видеть, что ты можешь развивать инструментарий SQL Server. Большое преимущество «открытого кода» в том, что вы можете встраивать в программный продукт то, чего вам не хватает, но мы были готовы встраивать в SQL Server то, чего там не было. Мы занялись централизацией управления маршрутами и обеспечением групповой рассылки сообщений. В то же время мы отобрали у разработчиков ряд сложных компонентов Service Broker, что позволило ускорить разработку базового приложения Service Broker. Оно стало центром для большинства коммуникаций в нашей среде. Оно полностью вытеснило репликацию. В дополнение к управлению транзакциями, приходящими с пользовательского уровня, приложение еще контролирует транзакции, инициированные с уровня баз данных. Кроме того, оно используется в транзакциях, которые коммутируются с другими слоями инфраструктуры. Для нас база данных – это не только точка получения информации, но и живая часть архитектуры, которая, при необходимости, может открывать коммуникации с промежуточным уровнем.

Для коммуникаций с промежуточным уровнем на вершине диспетчера Service Dispatcher мы построили приложение Tier Hopper. Мы начали с Service Broker, разработали Service Dispatcher, а затем надстроили продукты к Service Dispatcher. Мы надеемся поделиться этим с сообществом в полном объеме.

SQL Server Magazine: Что вы можете сказать о Service Broker, позволяющем вам заменить репликацию? Действительно ли его асинхронность способна уменьшить временные задержки?

Штельцмюллер: Да, именно асинхронность. Service Broker весьма устойчив к ошибкам в смысле восстановления. Хотя он использует диск, ему не нужен журнал регистрации.

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

Эль-Адван: Сложно восстанавливаться после сбоя репликации. У нас была практика применения «доморощенных» решений, поэтому мы были очень рады, когда SQL Server 2005 был выпущен с Service Broker.

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

SQL Server Magazine: Какие продукты сторонних производителей вы задействовали, чтобы контролировать и выполнять другие задачи на всех своих базах данных?

Джордж Тевелд, директор по администрированию баз данных
Джордж Тевелд, директор по администрированию баз данных

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

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

Штельцмюллер: Команда Джорджа в течение нескольких лет разрабатывала эти сценарии, и количество звонков, которые он получал от пользователей, упало с нескольких раз за ночь до раза в неделю.

Тевелд: Точнее, около трех раз в неделю. Сценарии решают приблизительно 40 % проблем, которые мы имеем. Они определяют, какая это процедура и перекомпилируют ее. Затем они идентифицируют проблему, например если это связано с таблицей, то они обновляют статистику по ней и начинают другой фрагмент и автоматически осуществляют перестройку индекса. Все это происходит в реальном времени без какого-либо участия специалиста. Сценарий выполняется и сообщает: «самое простое, что следует сделать, — это перекомпилировать хранимые процедуры». То же самое и для центрального процессора; а если это не работает, то он обновляет статистику по основной таблице в хранимой процедуре. Если это не сработает, сценарий находит наиболее фрагментированную таблицу, чтобы проверить, не превышается ли определенный порог. Затем он перестраивает все индексы, чтобы убедиться, что рабочая таблица очищена. Если и это не помогает, система, которая отслеживает сайт 24 часа в сутки, получает предупреждение, что имеется проблема с определенной хранимой процедурой; теперь вызывается администратор баз данных, который может прийти и посмотреть. У нас есть собственное информационное хранилище данных с описанием последних трех месяцев жизни сайта. Мы можем сказать: «За прошлые три месяца есть такая-то тенденция в центральном процессоре, и что-то изменилось за последние три часа». Затем мы смотрим эти последние три часа. Мы можем отменить изменение до прежнего уровня, исправить процедуру, или вызвать разработчика и сказать: «Мы должны собраться и поработать над этим».

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

Штельцмюллер: В прошлом мы обращали внимание на инструментальные средства для основных операций, таких как развертывание, потому что одновременно ввели в действие очень много баз данных. Реально никакое средство не удовлетворяло наши потребности именно так, как нам было необходимо, поэтому мы создали свой механизм – ExecuteSQL. Это инструмент, который выполняет SQL, как если бы он был запущен на единой базе данных, за исключением того, что он работает на 500 базах данных. Вы можете управлять уровнем распараллеливания, можете контролировать ошибки поведения; остановить и удалить операцию с помощью этого инструмента. Разрешены перемещения данных в рамках этого средства. Мы интегрировали его с Dispatcher; мы можем выполнять долгосрочные асинхронные процессы со всеми базами данных, что обычно и делаем, если планируем миграцию из-за перестройки специфической архитектуры данных или если должны внутри базы данных ввести секционирование для любой из наших больших таблиц. Этот инструмент допускает распараллеливание протяженных процессов в нашей федеративной модели и мы можем контролировать всю работу из единого центра.

SQL Server Magazine: На каких платформах вы работаете? В основном на SQL Server, 32 разряда? Есть ли у вас опыт работы на 64 разрядах?

Тевелд: Нет, мы всегда работали на 64 разрядах. Ограничение в 4 Гб на 32-разрядной платформе — причина, вынудившая нас с нее перейти, — сайт разрушался. Мы переключились на Windows Server 2003, 64-разрядный SQL Server 2005, и понизили загрузку центральных процессоров со 100 до 60 % только за счет модернизации серверов.

SQL Server Magazine: Каковы характеристики применяемых копанией серверов?

Тевелд: Это серверы HP DL585. Наиболее часто используется модель с восемью ядрами и четырьмя двухъядерными процессорами, которые работают с 64 Гбайт оперативной памяти.

SQL Server Magazine: Это довольно мощные серверы.

Тевелд: Да, но мы и их загрузили полностью. Сейчас мы планируем обновление, как только перейдем на Windows Server 2008 и SQL Server 2008. Мы собираемся использовать HP DL585, модель G6, у которой 128 Гбайт оперативной памяти и четыре четырехъядерника — всего 16 ядер.

Эль-Адван: Мы экспериментируем с базами данных: сколько их можно запустить на одном сервере. Мы провели анализ на различных версиях HP DL585, чтобы посмотреть, что будет «узким местом» в зависимости от имеющихся аппаратных средств. Мы меняем количество баз данных, запущенных на сервере, в зависимости от класса сервера, с которым имеем дело.

SQL Server Magazine: Сколько человек составляют команду разработчиков, которая добавляет все расширения к SQL Server, о которых вы упомянули?

Штельцмюллер: В нашей команде разработки данных есть группа инфраструктуры данных из трех человек. Это два архитектора данных и один старший разработчик. Они выполняют всю работу для встраиваемых расширений и несут ответственность за инструментальные средства развертывания и прикладные решения по управлению для всего, что имеет отношение к Service Broker.

Эль-Адван: Команда разработки базы данных включает 24 человека, но они в основном работают над функциями, связанными с продуктом. Мы начинали с двухуровневой архитектуры. Мы развивались; у нас есть обширный уровень кэширования, который находится между нашими базами данных и веб-серверами. В некоторых случаях это логически трехуровневая система, а в некоторых – это действительно физическая трехуровневая система. Мы стараемся отделить наши базы данных от логики представлений, оптимизировать код доставки данных в кэш, а также усовершенствовать сам кэш для соответствия на уровнях представлений и бизнес-логики. Модуль Tier Hopper имеет обратную связь со средним уровнем при всех процессах кэширования данных.

Штельцмюллер: Это также связано с непредсказуемостью операций чтения/записи, так как мы сосредотачиваемся, прежде всего, на обслуживании записи, а не операции чтения. Последнее мы оставляем нашему уровню кэширования.

Тевелд: Когда мы устанавливаем пакет обновлений и срочные исправления, это всегда непросто: какое бы время мы ни выбрали для приостановки работы на базе данных, пользователи будут не в состоянии войти на сайт и генерировать трафик. Нет трафика — нет денег. Самый большой простой вызывает запуск исправлений, который занимает до двух часов, и мы делаем это два или три раза в году. Всего 400 серверов, вне доступа в течение шести часов в год, получается 2400 часов в год — это довольно много. Microsoft объявила: «В Windows Server 2008/SQL Server 2008 вы можете создать кластерную среду. Вы можете устанавливать исправления для всего, начиная с SQL Server на пассивном узле, перезагрузить этот узел, не нарушая работы других серверов; затем вы можете воспользоваться одним из активных узлов, ввести его в пассивное состояние, при этом все прекрасно работает, а вы получили еще один узел, который можно подвергнуть установке исправлений».

Это основа высокой доступности, но для нас это было невероятно. Планируется, что в Windows Server 2008 и SQL Server 2008 все наши серверы будут кластерными. Мы собираемся установить структуры кластеров из 10 активных и одного пассивного узлов. Наша главная цель — время доступности. Эта мелочь приносит нашему сайту 2000 часов рабочего времени дополнительно, лишь на основании решения о кластеризации.

Эль-Адван: Одним из ключей, позволившим это сделать, была наша готовность переходить к Enterprise Edition.

SQL Server Magazine: Были ли другие аспекты SQL Server, которые вам нужно было расширить или улучшить? Были ли проблемы, с которыми вы столкнулись и которые приходилось решать?

Штельцмюллер: Да, мы сталкиваемся со всеми проблемами, которые распространены у этого семейства. Мы чрезвычайно активно используем XML, и XQuery захватывает нас, но захватывает недостаточно. В конечном счете, если документы становятся слишком большими, — он «душит». Необходимо создать собственный кусочек CLR, чтобы работать в среде XML; кое-что в этом направлении мы сделали.

Эль-Адван: У каждого, кто работал с репликацией на SQL Server в каком-то масштабе, были проблемы с надежностью и затруднения с одним дистрибьютором и репликацией. Мы остановились на многоуровневой системе дистрибьюторов. У нас есть одна исходная база данных, которая дублируется в четыре средних базы данных, а также имеет по дистрибьютору в каждой из этих ведущих баз данных, нацеленных на дублирование в некоторое число ведомых баз данных. Так, вместо того чтобы иметь одну ведущую базу данных, которую следовало бы скопировать в 500 баз данных, у вас есть одна ведущая на 10 промежуточных ведущих, каждая из которых будет дублироваться на свой набор баз данных.

SQL Server Magazine: Вы упомянули, что работали с Microsoft довольно близко, чтобы развернуть некоторые из особенностей SQL Server. Расскажите об этом подробней.

Эль-Адван: Когда я начинала в MySpace, у нас были проблемы масштабирования SQL Server. Мы дали понять Microsoft, каким уровнем знаний и опыта обладаем, смогли идентифицировать наши узкие места, и доказали, что мы знаем, о чем говорим. В конце концов, мы наладили связь с командой SQLCAT — с группой специалистов, которые не только общались с клиентами, но и очень хорошо разбирались в движке SQL Server (SQLCAT = SQL Server Customer Advisory Team — консультативная группа для клиентов). Они стали нашим ключом во всех контактах; это был первый шаг в формировании действительно сильного партнерства с Microsoft. Кроме того, мы взаимодействуем со множеством разработчиков SQL Server. Их интересует, как мы используем разработанные ими базы данных и инструменты, потому что наши масштабы, безусловно, впечатляют. Всякий раз, когда мы экспериментируем в Microsoft, мы встречаемся с разработчиками и различными группами в команде SQL Server, от нас они могут получить обратную связь по инструментам и понять цели, к которым мы стремимся.

Эль-Адван: Команда SQLCAT — это одна из очень сильных инвестиций Теда Куммерта, старшего вице-президента Microsoft, в систему SQL Server. У нас сложились гораздо более продуктивные отношения с командой SQL Server, чем с командой платформы Windows, именно потому, что команда SQLCAT этому способствует. Это больше похоже на партнерство, чем на отношения клиента и продавца, рекламирующего свой продукт.

Эль-Адван: И мы действительно смотрим на взаимодействие с командой SQL Server как на проект, на базе которого следовало бы выстраивать наши отношения и с остальной частью Microsoft.

Тевелд: Полезная вещь — отслеживание трендов. Мы производили выборку всех данных, которые суммировали каждые 15 минут, и сохраняли ее на отдельном сервере в течение трех месяцев. Даже если данные берутся в реактивном режиме, мы можем изучить тенденции и использовать их в превентивном режиме. Единственными проблемами, которые тормозят работу, сейчас являются аппаратные проблемы — например, неполадки с жестким диском, или что-то, чего вы не можете предсказать. Если сервер выходит из строя, наши сценарии перемещают файлы регистрации на другой сервер, и запускают неработающий сервер приблизительно за 20 минут.

Эль-Адван: Все это сценарии автоматизации. Аппаратные отказы — наша основная проблема, потому что мы используем Standard Edition, и не все наши инфраструктуры являются кластерными; но как только мы перейдем к модели кластеризации, это должно устранить тесную связь с базой данных на определенном сервере и добавить нам гибкости, чтобы восстановиться быстрее.

SQL Server Magazine: Могли бы вы сказать, сколько компаний находятся на этом же уровне и используют такое же количество серверов, как MySpace?

Штельцмюллер: Даже в меньших масштабах вы сталкиваетесь с теми же проблемами, только не так часто, как мы, с нашим количеством серверов. Мы должны упорно трудиться, чтобы выстроить все эти решения, потому что проблемы возникают часто. Прежде всего, это проблема ресурсов. Но инструментальные средства, которые мы имеем, будут полезны в любом проекте.

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

Штельцмюллер: Имеете ли вы дело с пятью DL585 или со ста DL585, вы все равно будете сталкиваться с теми же типами ограничений на единственном сервере или нескольких. Нам лишь приходится делать большее количество повторений.

SQL Server Magazine: А масштаб, в которым вы действуете, чаще вытаскивает проблемы на поверхность, чем в небольших или средних компаниях?

Тевелд: Ну да, если у вас есть один или два сервера и 10 пользователей, вы, возможно, столкнетесь с проблемами один раз в году. Но если у вас 400 серверов, загруженных до предела, то раз или два в неделю мы встречаемся с четырьмя или пятью инцидентами. Но благодаря сценариям мы сможем определить, в чем состоят неполадки. А после того как находится путь решения, мы добавляем его в свою систему контроля и базовых знаний.

SQL Server Magazine: Интересно было бы узнать, на каком количестве итераций по выявлению-устранению огрехов будет остановка в следующей версии SQL Server.

Штельцмюллер: Мы сталкиваемся с некоторыми ошибками, к которым средняя по масштабам реализация может и не приблизиться. Но ошибки есть для всех, вопрос — натолкнетесь вы на них сегодня или год спустя.

SQL Server Magazine: Как вы организуете резервное копирование для такого количества серверов с важной информацией на разных серверах, как справляетесь с этим?

Эль-Адван: Мы используем решение 3PAR (3PAR.com) для своей системы хранения данных SAN. У нас порядка 14 систем 3PAR для всех производственных баз данных. Имеется два совместных сервера, в которых «живут» наши данные, и еще 14 систем, их обслуживающих. У нас есть 4 сервера резервного копирования, которые мы называем «ближними», с установленными на всех дисками SATA. Ближние серверы расположены вместе с двумя совместными. Для резервного копирования мы делаем мгновенные снимки базы данных раз в день на каждом из 3PAR серверов. Мы поддерживаем три версии этих снимков для наших «живых» промышленных базах данных, а затем делаем репликацию этих снимков на другой совместный сервер на диски SATA. Таким образом, у нас имеется три «горячих» снимка данных на промышленных серверах и три резервных копии на ближних и совместных. Мы были в восторге от такого решения, а компании 3PAR он понравился настолько, что у них подумывают о предложении этого метода другим клиентам.

Штельцмюллер: Microsoft заявила, что мы представляем крупнейшую реализацию на SQL Server с точки зрения транзакций и объемов данных. Очень важно показать, на что способен и с чем может справляться SQL Server. Я знаю, что многие люди, как правило, недооценивают его как платформу, но, думаю, это говорит лишь о пределах их воображения.

SQL Server Magazine: Многие думают об SQL Server как о бизнес-системе среднего размера, но вы доказали, что он может участвовать в довольно крупном бизнесе.

Эль-Адван: У нас есть девиз: дело не в платформе, дело в архитектуре. Платформа — не главное, надо просто знать, как ее настроить.