Хотя 64-разрядная версия сервера SQL Server 2000 Enterprise Edition существует на рынке уже два года, многие организации с трудом решаются его приобрести. Я много беседовал с клиентами, администраторами баз данных и разработчиками, которые отказываются от 64-разрядной версии, потому что думают, что она предназначена только для приложений, ориентированных на очень большие базы данных (VLDB) или на развертывание массивных аналитических служб OLAP. Многие считают, что эта версия слишком дорого обойдется предприятию. Однако существует три практических сценария, которые могли бы заставить руководство организации все-таки потратить деньги на 64-разрядную версию. Давайте коротко обозначим преимущества 64-разрядной версии SQL Server. Эта версия может обеспечить консолидацию баз данных, объединить бизнес-логику (BI) и работать в кластере с несколькими экземплярами SQL Server.
Принимая во внимание эти выгоды, следует учитывать, что, говоря о сервере с версией SQL Server 2000 Enterprise Edition (64-разрядная редакция), пользователи часто имеют в виду платформу Intel Itanium2, также известную как 64-разрядная платформа Intel Architecture (IA64) или Itanium Processor Family (IPF). Описание возможностей платформы Itanium2 приведено во врезке «Опять Itanium Inside». Itanium2 — единственная платформа для 64-разрядной версии SQL Server 2000. Однако версия SQL Server 2005 будет поддерживать IA64 и x64 на процессорах AMD и Intel x64.
Консолидация баз данных SQL Server
Серверы баз данных — главные кандидаты в консолидированные серверы. Недавнее исследование 251 компании показало, что проекты консолидации баз данных сулят относительно низкие затраты, упрощение администрирования и улучшение качества реализации баз данных в силу сокращения числа экземпляров базы данных.
Консолидация баз данных — хорошая идея, но в 32-разрядном окружении есть определенные недостатки. Если в проекте консолидированной базы данных предполагается задействовать платформу традиционного 32-разрядного сервера, то такой SQL Server сможет иметь собственные адреса только в пределах 4 Гбайт, а приложения могут изначально обращаться только к 2 Гбайт памяти из-за того, что ядро операционной системы резервирует 2 Гбайт для себя. Это ограничение можно обойти, используя дополнительные ключи /PAE и /3GB в файле boot.ini, которые переводят сервер в режим расширения физической адресации (далее PAE) и позволяют неядерным приложениям использовать до 3 Гбайт памяти. Следует принять во внимание, что все приложения сервера, включая те, о которых обычно мы забываем, вроде антивируса или монитора приложений, должны совместно использовать эти 3 Гбайт. Address Windowing Extensions (далее AWE) позволяет обращаться к памяти за пределами 4 Гбайт, но многие ресурсоемкие процессы не могут обращаться к памяти AWE. При этом, как только включается PAE, отключается возможность SQL Server в динамическом управлении памятью. Таким образом, SQL Server, однажды заняв память, не будет ее освобождать, если не перезапустить его.
Если функция AWE включена, ошибочно было бы предполагать, что можно объединить сотни баз данных в мощный 32-разрядный сервер с объемом памяти 8 либо 16 Гбайт или больше, а также эффективно управлять консолидированной нагрузкой с помощью AWE за пределами физических 4 Гбайт. Если исследовать деятельность пула памяти SQL Server, когда один сервер содержит много баз данных, можно увидеть, что каждая база данных требует дополнительного места для содержания объектов метаданных для каждой из баз (по-другому системные структуры данных) для всех сущностей и имен атрибутов, типов данных, блокировок таблиц и т. д. То есть каждая база данных имеет группу пользователей (или прочих приложений) которые подсоединяются к ней. Каждому соединению к базе данных назначается область в пуле памяти, в котором хранится: информация значений параметров для запросов и хранимых процедур, информация по позиции курсора, текущие ссылки на таблицы и промежуточные результаты запроса при работе со сложными многошаговыми планами запросов. Некоторые из этих элементов могут быть весьма большими. Ни системные структуры данных, ни конструкции контекста соединения в пуле памяти не могут использовать AWE. Они должны работать внутри собственных 4 Гбайт памяти 32-разрядной платформы. Кроме того, кэш процедуры не может использовать AWE и AWE не разрешает хранение промежуточных результатов запроса при выполнении сложных, многошаговых планов запроса, потому что эти результаты также хранятся в области контекста соединения в пуле памяти. Отсутствие поддержки AWE для контекста соединения может «поставить на колени» приложения OLTP или любые приложения хранилищ данных. Эта проблема обостряется при консолидации, когда многочисленные базы данных конкурируют за память.
Теперь, когда я в столь мрачных тонах обрисовал консолидацию базы данных в случае 32 разрядов, давайте рассмотрим как альтернативу 64 разряда. Архитектура на 64 разрядах теоретически может обращаться к 18 эксабайт памяти (это 18 млрд. байт, что в 4,3 млрд. раз больше, чем на 32 разрядах). Тем не менее существующие системы на 64 разрядах ограничены аппаратными средствами и программным обеспечением, на котором они выполняются. Если сервер работает на процессоре Itanium2 и поддерживает достаточный объем памяти, Windows 2003 позволит построить сервер с использованием до 512 Гбайт оперативной памяти. С таким количеством доступной памяти можно незамедлительно устранить все ограничения, возникающие в примере с 32-разрядным SQL Server, и обеспечивать огромную, плоскую, собственную распределенную адресацию памяти для консолидированных экземпляров SQL Server.
После того как узкие места памяти выявлены, становятся очевидны возможности процессора Itanium2. Мало того, что процессор на 64 разрядах обращается к большему количеству оперативной памяти, но и его архитектура может обращаться к памяти быстрее (в силу большего количества и большей ширины шин). Также Itanium2 обладает большим кэшем уровня Level 3 (L3), а это означает, что процессор имеет больше локальной памяти, от 3 до 9 Мбайт. Это способствует устранению повторных обращений за необходимой информацией к банку оперативной памяти. 64-разрядная архитектура и процессор Itanium2 в частности лидируют в параллелизме и выполнении упреждения, что позволяет одному процессору одновременно обрабатывать многократные наборы команд, различать, какой код может потребоваться после, и выполнять его. Эти способности к объединению позволяют уменьшить количество процессоров, необходимых для консолидации базы данных, что значительно уменьшает затраты на лицензирование SQL Server.
Консолидация BI
Рассматривая консолидацию базы данных, мы обозначили некоторые из проблем, вызванных ограничениями 32-разрядной памяти в соответствующем реляционном процессоре SQL Server. При внедрении аналитических служб Analysis Services for BI 32-разрядная архитектура имеет подобные и иногда более строгие ограничения. Дело в том, что Analysis Services не поддерживают AWE. Analysis Services — удивительный продукт, он позволяет работать с внушительными запросами по связанным хранимым данным и создавать хранилища данных OLAP из подробных данных и суммарных значений или агрегаций, и все в сжатом формате. Analysis Services используют это сжатое хранение данных, чтобы обеспечить быстрый отклик (часто до секунды) на запрос. Но за эти функциональные возможности тоже приходится платить. Когда Analysis Services запускаются, они кэшируют размерности (которые являются многомерными сущностями или сущностями OLAP) в памяти, и данная операция проходит превосходно, до тех пор пока нет необходимости в кэшировании размерностей Customer или Product, содержащих 5, 10 или 15 млн. записей. А при обработке размерностей любая старая копия (или дубликат) размерности остается на месте, пока обработка новой копии не закончится и новая копия не будет заменена старой. Возможно, в организации также имеется собственная система безопасности, гарантирующая, что только некоторые пользователи могут видеть отдельных клиентов или определенную информацию о продукте. В таком случае каждое назначение роли для размерности требует, чтобы отдельная, собственная копия размерности находилась в кэше памяти. И становится понятно, как одни только размерности аналитических служб могут быстро израсходовать всю память, даже без учета кубов, к которым эти размерности принадлежат, содержащих все детальные фактические записи. Ограничения памяти 32-разрядных Analysis Services, наряду с запросами на память при заполнении кубов детализированными данными и агрегациями, заставляют разработчиков приложений BI рассматривать вопрос о 64-разрядном выделенном сервере для Analysis Services.
Один из способов улучшить производительность Analysis Services состоит в том, чтобы поместить собственно реляционные данные в экземпляр SQL Server на том же самом сервере, что и Analysis Services. При обычной установке Analysis Services кубы загружаются на выделенный для аналитики сервер, выполняющий запросы к выделенному SQL Server по TCP/IP или именованным каналам. Сетевые подключения часто становятся узким местом. Но если Analysis Services и SQL Server находятся на одном и том же узле, Analysis Services могут соединяться с SQL Server через общедоступную память, которая позволит загружать кубы и доставать данные из SQL Server с быстротой молнии. Конечно, уровень производительности повышается в зависимости от скорости дисковых операций ввода/вывода и остальных факторов.
Этот фокус с большой производительностью исключает вариант с 32-разрядной платформой, которая не обеспечивает достаточно адресуемой памяти, чтобы позволить SQL Server и Analysis Services мирно сосуществовать даже на системе среднего размера. Но с 64 разрядами ограничений по памяти нет, и обработка происходит на увеличенных вычислительных мощностях, что делает 64 разряда оптимальным решением для консолидации архитектуры BI. Когда имеется 32-разрядный четырехпроцессорный сервер с SQL Server и 32-разрядный четырехпроцессорный сервер с Analysis Services, их можно объединить на 64-разрядном четырехпроцессорном сервере BI. Имея достаточно памяти и процессорной мощности, можно поддерживать SQL Server (вмещающие реляционное хранилище данных) и Analysis Services (вмещающие многомерную витрину данных). Поскольку наполнение хранилища данными подразумевает большое количество массовых операций, можно получить высокую производительность для реляционных и OLAP-уровней при меньших общих затратах, поскольку лицензии на аппаратное и программное обеспечение используются более эффективно и мы избавляемся от одного сервера.
Кластеры из нескольких экземпляров SQL Server
Поскольку компонент Microsoft Clustering Services (MSCS) в версиях Windows 2003 и Windows 2000 тщательно проработан, SQL Server занимает прочное положение на рынке, потому что позволяет обеспечивать высокую надежность в работе с данными при запуске на отказоустойчивом кластере Windows (не путать с кластерами со службой Network Load Balancing, используемыми Web-фермами в Internet). На рис. 1 показан обычный отказоустойчивый кластер в активно-пассивной конфигурации, состоящий из двух узлов: первичного и резервного. Такая архитектура надежна, но может оказаться дорогостоящей. Компания Microsoft не требует лицензии SQL Server на резервный узел в кластере, но придется потратиться на «железо» и операционную систему (для поддержки кластера необходима версия Enterprise Edition) плюс накладные расходы на администрирование пассивного сервера. Если на предприятии имеется несколько критических экземпляров SQL Server с разными назначениями, каждый требующий наличия кластерной среды, поддержку двумя серверами каждого экземпляра можно организовать быстро. Альтернативный, экономичный вариант — кластер мультиэкземпляров (иначе активно-активный кластер), в котором имеется два узла, причем каждый действует как первичный узел для экземпляра SQL Server и как резервный узел для других экземпляров, как показано на рис. 2. Такая архитектура позволяет полностью использовать все вложения в аппаратные средства и в операционные системы, при этом к небольшим административным накладным расходам добавляются только стоимость лицензии на SQL Server для второго узла кластера. Данная архитектура хорошо работает в среде, где нет больших баз данных, высокого параллелизма или чрезмерно сложных запросов. Но если при обработке отказа имеет место требовательная к объему памяти активность в случае экземпляров баз данных, собранных в кластер, как в сценариях консолидации баз данных, два экземпляра SQL Server конкурируют за всю доступную оперативную память и вычислительные возможности сервера. При этом вся обработка в обоих экземплярах базы данных SQL Server значительно замедлится.
Концептуально и логически в архитектуре кластера для нескольких экземпляров нет ничего неправильного, но в физическом адресном пространстве памяти размером 4 Гбайт это не работает, да еще и при ограниченных вычислительных возможностях 32-разрядного сервера. Однако, если кластер из мультиэкземпляров размещен на 64-разрядном «железе», он обладает большей мощностью для того, чтобы поддержать отказоустойчивость, и при этом нагрузка при обработке сбоя для конечных пользователей будет практически незаметна. Конечно, нужно соответствующим образом настроить серверы с необходимым количеством дополнительной памяти так, чтобы можно было реализовать все преимущества, но и такие затраты вполне сравнимы с затратами на поддержание дорогой активно-пассивной модели. В активно-активной модели немедленно компенсируются затраты на 64-разрядное «железо» и затраты на увеличение памяти, потому что все «железо» и программное обеспечение активно используется, а не ожидает своей очереди в пассивном режиме.
Некоторые реализации, используя Windows 2003 Enterprise Edition или Windows 2000 Datacenter Edition, могут создавать кластер в архитектуре N+1, в которой кластер, например, мог бы содержать четыре узла, из них три активных и один резервный, используемый в случае сбоя другими узлами. При анализе затрат такая архитектура на экземпляр базы обходится дешевле, чем двухузловой кластер с одним экземпляром (активно-пассивный) даже с 32-разрядной архитектурой, потому что используется больший процент аппаратных средств, в которые сделаны вложения. Но даже эта модель может быть в дальнейшем усовершенствована, если использовать 64 разряда. Если имеется кластер N+1 на 32 разрядах и на более чем одном узле произошел отказ, потребуется ручное вмешательство (или создание достаточного количества сценариев с cluster.exe) и тщательный контроль процесса обработки сбоя или восстановления. Иначе можно потерять все экземпляры SQL Server, работающие только на одном узле кластера и при возможном отсутствии достаточных ресурсов для запуска всех экземпляров на одном 32-разрядном узле. Но 64-разрядное оборудование позволяет создать кластер с памятью и производительностью, необходимой для того, чтобы выдержать такой тип последовательных цепных сбоев с меньшим ущербом для конечных пользователей, так что будет время, чтобы благополучно провести процедуру восстановления даже после катастрофического отказа оборудования.
Время вкладывать деньги
От 64-разрядных продуктов, построенных на Itanium2, Opteron и расширениях Xeon, можно ожидать многого. SQL Server 2005 будет включать в себя соответствующие этим продуктам версии Intergration Services, Reporting Services и Notification Services, набор утилит клиента. Если планируется приобретать новые серверы и снизить затраты, оставаясь на 32-разрядных системах, следует еще раз продумать, как 64-разрядная система могла бы обслуживать текущие и будущие потребности. Возможно, она стоит того.
Дуглас Макдауэлл - преподаватель, менеджер проектов по Business Intelligence в Solid Quality Learning. Имеет звания MCSE, MCDBA и MCT. douglas@SolidQualityLearning.com
Опять Itanium Inside
Кристалл Itanium от Intel обозначил новое направление в мире процессоров. В отличие от более ранних CISC-процессоров типа x86 и разработок RISC, таких как Sun Sparc, Itanium — это процессор с длинным командным словом Very Long Instruction Word (VLIW). Процессоры VLIW читают строковые команды, или «слова», составленные из нескольких инструкций. Несколько специализированных процессоров использовали архитектуру VLIW, а кристалл Itanium стал известен как первый универсальный процессор общего назначения.
Архитектура Itanium ушла далеко от архитектуры x86, избавившись от ошибок в операциях с плавающей точкой, которые долго преследовали семейство x86. Эта отличительная особенность позволяет Itanium демонстрировать более высокую производительность, чем x86, но за это заплачено несовместимостью. Itanium может выполнять 32-разрядные программы x86 только в режиме эмуляции, при этом не показывая хорошую производительность. Как и было задумано, процессор Itanium больше напоминает высококачественный RISC-процессор, чем своего предшественника x86. Тем не менее есть одно существенное отличие между Itanium и технологией современных RISC-процессоров — в использовании в Itanium усовершенствованных технологий параллельной обработки. Не путайте этот тип параллельной обработки с параллельной обработкой, которую обеспечивают мультипроцессорные системы SMP типа Xeon. Параллелизм процессора Itanium происходит от способности центрального процессора обрабатывать более одной команды за раз, — задача, с которой большинство RISC-систем справляется плохо. Intel назвала новую схему параллельной обработки Explicitly Parallel Instruction Computing (EPIC). Архитектура EPIC может обрабатывать до шести команд за такт одновременно. Способность выполнять много команд за цикл делает обычные измерения производительности основанными исключительно на скорости тактового генератора и вводящими в заблуждение в случае процессора Itanium.
В отличие от процессора Pentium, архитектура EPIC не требует от процессора выполнения сложных неупорядоченных операций обработки с целью достижения быстрой оптимизации. Вместо этого задача распараллеливания машинных команд ложится на компилятор. Компилятор читает исходный код программ и создает команды для исполнения процессором. Это означает, что компилятор должен определить взаимозависимости каждой команды, а также то, какие команды должны выполняться параллельно. Такой «переключатель обязанностей» позволяет упрощать работу процессоров без необходимости в планировщике команд или скрытых регистрах. Впрочем, это также означает, что эффективность работы центрального процессора в значительной степени зависит от возможностей компилятора с точки зрения оптимизации кода для параллельной обработки.
Другая особенность процессора Itanium тесно связана с параллелизмом и называется предсказанием ветвлений. Предсказание ветвлений — это технология компиляции, позволяющая прогнозировать, код из какой ветви исполнения будет использовать программа на следующем шаге исполнения. Современные процессоры типа Pentium используют предсказание ветвления. При предсказании ветвления процессор затрачивает часть своего времени на обработку как связанного кода, который будет на следующих шагах исполняться, так и на обработку ненужных ветвлений. Предсказание ветвлений в компиляторе позволяет процессору Itanium делать более точные прогнозы о том, какие логические ветви приложение будет использовать, избавляясь от ненужных вычислений и позволяя процессору работать более эффективно.
Хотя кристалл Itanium третьего поколения, Itanium2, работает на средних (по стандартам 32-разрядной архитектуры) скоростях, от 1,30 до 1,60 ГГц, конструкция Itanium способна обрабатывать 6 гигафлопов
(6 млрд. операций с плавающей точкой в секунду). Процессор Itanium2 имеет встроенный кэш Level 1 (L1) емкостью 32 Кбайт и кэш уровня L2 на 256 Кбайт и может получить доступ вплоть до 9 Мбайт внешнего кэша уровня L3. Процессор содержит четыре целочисленных блока, два блока операций с плавающей точкой и 328 регистров для хранения чисел и команд. Процессор использует новый интерфейс материнской платы Slot М и 128-разрядную системную шину с частотой 400 или 533 МГц. Компания Intel создает Itanium2, используя 13-микронный технологический процесс (чем меньше норма технологического процесса, тем выше производительность). Поскольку процессор был разработан с прицелом на создание передовой высокотехнологичной платформы суперкомпьютера, Itanium позволяет создавать SMP серверные системы, содержащие до 512 процессоров (дополнительную информацию об Itanium2 можно найти по адресу).
Майкл Оти - Старший технический редактор Windows IT Pro и президент компании TECA. С ним можно связаться по адресу: mikeo@teca.com