База данных является для OpsMgr одним из самых критичных компонентов. Именно от нее во многих случаях зависит то, что можно назвать “впечатлениями от работы с продуктом”. Как ни странно, но именно в части планирования базы данных(и SQL Server) допускается большинство ошибок при развертывании OpsMgr. В основном из-за недостаточного внимания, которое уделяют БД при планировании. Я опишу несколько основных моментов, про которые нужно помнить(и учитывать их) при планировании новых инсталяций(да и при настройке и “тюнинге” уже существующих).~~~
Начнем с самого простого. С поддерживаемых конфигураций. Разработчики ПО(в частности, Microsoft) не просто так указывают конфигурации, которые называют поддерживаемыми. Эти конфигурации имеют несколько важных преимуществ перед остальными(теми, которые не указаны как поддерживаемые):
- Они протестированы. То есть разработчики уже успешно эксплуатировали продукт в заявленных как поддерживаемые условиях.
- В случае, если будет найдена ошибка или проблема, для поддерживаемых конфигураций выйдет исправление. Для неподдерживаемых – скорее всего исправлений не будет.
- Заказчики, которые используют поддерживаемые конфигурации, будут обеспечены технической поддержкой. Все остальные должны быть морально готовы услышать “данная конфигурация не поддерживается” в ответ на обращение в техподдержку со своей проблемой.
- В неподдерживаемых конфигурациях могут быть проблемы, о которых знают разработчики, но могут и не догадываться простые заказчики. С производительностью, соместимостью компонент и еще миллионом всяких нюансов. К чему это я? К тому, что если продукт успешно установился и даже на данный момент неплохо работает в неподдерживаемой конфигурации, это совсем не значит, что разработчики ошиблись, не включив данную конфигурацию в список поддерживаемых. Вполне возможно, что вы еще не “наступили на грабли” из-за которых данная конфигурация не поддерживается. Или наступили, но пока еще об этом не подозреваете :)
Вернемся к базе данных OpsMgr. А точнее к поддерживаемым конфигурациям. Поддерживаемые компоненты для развертывания БД:
Операционная система: Windows Server 2003, Windows Server 2003 R2 или Windows Server 2008(редакции Standard, Enterprise или Datacenter; архитектура х64 или х86(32-битная);Service Pack1 или более поздний). Отмечаем для себя, что слов “Itanium” или “IA64” не наблюдается.
CPU: Рекомендуется не менее 2.8 GHz
RAM: Рекомендуется не менее 4 GB
Дисковое пространство: рекомендуется 50 GB
SQL Server: SQL Server 2005 (Standard или Enterprise, Service Pack 1 или более поздний) или SQL Server 2008 Service Pack 1 или более поздний. Использование 32-битного SQL Server, установленного на 64-битной операционной системе НЕ поддерживается.
SQL collation: только SQL_Latin1_General_CP1_AS
Минимальная скорость передачи данных между management server(неважно, RMS это или простой менеджмент сервер) и SQL Server с операционной БД - 256 Kbps. То есть, располагать менеджмент серверы на удаленных площадках, связанных с расположением SQL Server с операционной БД более медленными каналами – плохо.
Более подробно все это можно посмотреть(включая поддерживаемые конфигурации для кластеров) в документе Operations Manager 2007 R2 Supported Configurations
Дополнительные рекомендации
Используйте 64-битные операционные системы везде, где это возможно. Это позволит, например, достаточно легко при необходимости увеличивать объем RAM свыше 4 Гб.
Располагайте файлы базы данных и файлы журнала транзакций на разных физических дисках.
Измените размер БД tempdb(и ее журнала транзакций) до 20% от размера операционной базы данных(OperationsManagerDB). Или до 20% от суммарного размера операцонной базы данных и БД DataWarehouse, если они расположены в одном экземпляре SQL Server.
Отдельно о дисковой подсистеме для SQL Server
Используйте RAID 10 для дисковых подсистем, предназначенных для БД. Помимо этого крайне рекомендую ознакомиться с этой записью в блоге разработчиков: Performance IOPS for the DB and DW in OpsMgr 2007 и, особенно, сходить по приведенной ими ссылке.
Крайне рекомендую ознакомится со Storage Top 10 Best Practices из документации к SQL Server 2005. Также, для тех, кто подзабыл – быстрый экскурс в RAID применительно к SQL Server. Вот здесь есть еще ссылки на статьи, касающиеся производительности SQL Server: Microsoft SQL Server Database Engine Input/Output Requirements
Думаю, здесь можно сделать небольшую остановку, чтобы отметить важность производительности дисковой подсистемы SQL Server для общей производительности OpsMgr. OpsMgr очень ресурсоемок, он генерирует очень значительное количество операций со своей БД. Вы все еще собираетесь устанавливать SQL Server для БД OpsMgr в виртуальную машину?
Для того, чтобы спланировать необходимое именно для вашего случая оборудование используйте Microsoft System Center Capacity Planner 2007 и модель для Microsoft System Center Operations Manager 2007. Для приблизительного планирования необходимого дискового пространства для БД(и будущего размера вашей БД) можно использовать Database Size Calculator for OpsMgr 2007.
Не забывайте оставлять на дисках, где расположены файлы БД свободное место, хотя бы еще столько же, сколько у вас требуется для БД по калькулятору. Заменить диск на более емкий может быть достаточно трудозатратно, если вдруг у вас случится неожиданный “шторм” алертов и база данных резко прибавит в размере. Или появятся требования по подключению большого количества дополнительных агентов(которые вы изначально не планировали) и дополнительных менеджмент паков.
Настройки очистки операционной базы данных(grooming settings):
По умолчанию все периоды хранения, кроме Performance Signatire, установлены в семь дней. Учитывая влияние размера БД на производительность OpsMgr(и, в частности, на производительность UI) будет вполне рациональным установить более короткие периоды хранения. К примеру – два дня. Особенно это актуально в период развертывания и начальной настройки, когда есть большая вероятность появления множества “шумовых” алертов и прочих не особо нужных данных. Укороченые периоды хранения данных не дадут вашей БД “распухнуть” от не самой важной информации в период начальной “обкатки” продукта.
В целом, такие короткие периоды хранения лучше оставить. Вы можете их изменить в любой момент, если у вас появилась необходимость хранить данные в операционной базе дольше. Но тут важно понимать, что для долгосрочного хранения собранных данных с целью их анализа предназначена БД DataWarehouse. Все данные(алерты, данные о производительности, события) параллельно пишутся в DW(при ее наличии, конечно) и никуда не “пропадают” после того, как будут удалены из операционной БД. Так что смысла хранить данные долго в операционной базе как правило нет.
Recovery model для БД
По умолчанию всегда – Simple. До тех пор, пока у вас нет четкой необходимости изменить ее. Например, вы хотите использовать log shipping.
Autogrow
Всегда отключен. Кстати, процедуры апгрейда(с RTM на SP1 или с SP1 до R2) автоматически отключают autogrow. Вы можете его включить, но при этом нужно помнить несколько моментов:
1. Включение autogrow должно рассматриваться только как мера для выигрыша времени в случае, например, большого “шторма алертов”. Ни в коем случае не пускайте рост базы на самотек. Резкий рост базы часто сигнализирует о проблемах или неудачно выбраной конфигурации. Впрочем, как и слишком большой размер БД.
2. Когда вы включаете autogrow – всегда ограничивайте рост БД. Хороший уровень – 80% от размера БД.
3. Когда вы включаете autogrow – всегда указывайте увеличение БД в Гб, а не в процентах.
Соотношение размеров БД и ее журнала транзакций
Для журнала транзакций рекомендуется размер от 20 до 50 процентов от размера БД. Чем меньше размер БД – тем больше можно делать размер журнала транзакций. Например для баз размером до 10Гб подходящим будет 50%, а для очень больших БД(свыше 30Гб) – 20%.
Свободное место внутри самой БД
Нужно поддерживать минимум 40% свободного места внутри БД. В OpsMgr есть специальный монитор, который следит за свободным местом в операционной БД и переходит в “Warning” при наличии менее 40% свободного места и в “Error” при менее, чем 20% свободного места. Это нужно для того, чтобы у вас всегда было простарнство на случай внезапных “штормов” событий или массового добавления данных. Вы ведь помните, что по умолчанию autogrow отключен?
Два заключительных слова
В целом это, наверное, все основные моменты, которые нужно помнить и учитывать. Кроме этого нужно помнить, что операционная БД в штатных ситуациях обслуживает сама себя. То есть избавляется от устаревших данных, индексируется и т.п. Единственное, что вы должны делать самостоятельно – резервное копирование.
Надеюсь, что я ничего не забыл и ваши БД(и OpsMgr) теперь будут демонстрировать чудеса производительности. :)