Материал предоставлен сайтом www.learn1c.ru/
Cвершилось! Вы созрели для перевода базы 1С в формат SQL, и радость от принятия такого решения омрачает лишь одно - Вы не знаете с чего начать.
Эта статья, надеюсь, поможет Вам определиться, что и в каком порядке Вам следует сделать, чтобы обойти возможные подводные камни. Скажу сразу, здесь не будет рекомендаций по выбору конкретного "железа" и процедуре переноса базы на SQL сервер. Это отдельные вопросы, ответы на которые можно найти в методической литературе и форумах в Интернете.
Здесь я расскажу Вам о принципах, которых Вам следует придерживаться при выборе и настройке SQL сервера.
Выбираем сервер
Я думаю, Вы переводите 1С на SQL с целью увеличения надежности и нагрузочной способности программы. Поэтому уделите особое внимание выбору сервера, на котором будет выполняться программа MS SQL Server (в статье будет рассматриваться MS SQL Server 2000, далее по тексту - SQL сервер):
- Сразу выбирайте настоящий сервер, т.е. компьютер с серверной архитектурой. Тем самым Вы избавите себя от головной боли в будущем, когда по неизвестным причинам будет рушиться база 1С, перезагружаться компьютер, и добавление диска будет превращаться в неразрешимую задачу.
Это требование особенно актуально для предприятий, на которых выход из строя информационной системы влечет за собой большие убытки. Примите это во внимание, если все-таки склоняетесь к покупке обычного компьютера. - На сервере желательно наличие 2х и более процессоров. Это связано с тем, что SQL сервер может эффективно использовать несколько процессоров для распараллеливания задач. К тому же в многопроцессорной среде не будет столь явной конкуренции за процессорное время между операционной системой и SQL сервером.
- Убедитесь, что на сервере установлена гигабитная сетевая карта. Этим требованием можно пренебречь, если Вы планируете организовать терминальный сервер, на котором будут работать и 1С, и SQL сервер.
- Не экономьте на оперативной памяти.
Конечно, не следует ставить 16ГБ памяти на сервер под управлением MS Windows Server 2003 Standard Edition (32-разрядная версия). Это будет пустой тратой денег, так как эта редакция Windows поддерживает только 4 ГБ памяти.
В то же время установка 2ГБ памяти при тех же условиях будет тоже нерациональной, так как SQL сервер не сможет воспользоваться всеми 2ГБ, которые теоретически ему может выделить операционная система.
Выбор объема оперативной памяти зависит как от версии операционной системы, так и от редакции SQL сервера. Например, если Вы собираетесь использовать MS Windows Server 2003 Standard Edition (32-разрядная версия) и MS SQL Server 2000 Standard Edition, ставьте 4ГБ памяти.
Примечания: ограничения по памяти для различных версий Windows Вы можете посмотреть в статьях "Memory Limits for Windows Releases" и "Memory Support and Windows Operating Systems".
Данные о максимальном объеме оперативной памяти, который может использовать каждая редакция SQL сервера, можно найти в Books Online (BOL) по строке поиска "Maximum Amount of Physical Memory". Небольшой фрагмент этой таблицы приведен ниже:
- Заранее определите, сколько жестких дисков Вам понадобится. Этот вопрос будет рассмотрен далее в статье.
- Позаботьтесь, чтобы сервер позволял менять вышедшие из строя диски в "горячем" режиме, т.е. без выключения сервера. Обычно для этих целей в серверах применяются специальные корзины для жестких дисков.
- Выбирайте сервер с таким расчетом, чтобы в будущем в него можно было установить еще несколько дисков. Такой ход событий очень вероятен, так как при эксплуатации программы может обнаружиться, что сервер "тормозит" именно из-за дисковой подсистемы.
- Используйте RAID-контроллер с батарейкой. Это позволит Вам сохранить данные даже в случае обесточивания сервера.
- Отдавайте предпочтение серверу, в котором несколько блоков питания. Причина очевидна - если один блок питания выходит из строя, Ваш сервер будет продолжать работать на оставшихся исправных блоках питания.
К тому же, если требуемое количество жестких дисков будет велико (например, через полгода Вы решите усилить дисковую подсистему), может выйти так, что один блок питания не сможет "вытянуть" такую нагрузку, и сервер будет работать нестабильно (если вообще будет). - Всегда подключайте сервер к мощному источнику бесперебойного питания (ИБП), который сможет обеспечить время автономной работы не менее 30 минут. За это время пользователи сумеют завершить свою работу в 1С, а Вы - не торопясь выключить сервер.
В наличии мощного ИБП есть еще один плюс: за промежуток времени между отключением электричества и выключением сервера батареи ИБП не успевают сильно разрядиться. Таким образом, если за первым отключением через небольшой интервал времени последует второе, ИБП будет в состоянии держать нагрузку, и Вы во второй раз выключите сервер без риска потерять данные.
На этом перечисление общих требования к серверу закончено, и сейчас самое время узнать, сколько же надо жестких дисков, чтобы SQL сервер работал быстро и надежно.
Определение количества жестких дисков
Давайте попытаемся определить, какое минимальное количество жестких дисков необходимо установить на сервер, чтобы создать благоприятные условия для работы SQL сервера. В то же время будем помнить об ответственности, которая возложена на этот сервер. Мы должны спроектировать дисковую систему так, чтобы выход из строя одного диска не привел к остановке сервера.
Начнем с операционной системы. Согласитесь, будет неприятно, если хорошо настроенный SQL сервер "упадет" из-за поломки винчестера, на котором установлена операционная система. Поэтому примем решение устанавливать систему на 2 диска, объединенные в RAID1. В этом случае даже если один винчестер выйдет из строя, сервер будет продолжать работать на втором.
Примечание: рассмотрение уровней RAID выходит за рамки данной статьи. Подробную информацию по этой теме Вы можете получить из BOL, используя строку поиска "RAID", а также из многочисленных статей в Интернете, например, "Конфигурирование и планирование подсистемы ввода-вывода".
Следующий этап - определение количества дисков для базы данных в формате SQL. SQL сервер хранит базу данных как минимум в 2х файлах:
- файл данных (*.mdf);
- файл транзакций (*.ldf).
Важность информации, хранящейся в этих двух файлах, переоценить сложно, - это Ваши данные. Готовы ли Вы потерять свою информацию из-за поломки жесткого диска? Скорее всего, нет. Я тоже так думаю. Поэтому давайте разместим эти файлы на надежном массиве RAID1. Это еще 2 диска.
Вы скажите, зачем мне еще 2 диска, когда операционная система установлена на RAID1, и места там еще предостаточно. Уверяю Вас, размещать файлы базы данных на том же диске, что и операционная система, не самое лучшее решение. Сейчас объясню, почему это так.
Сымитируйте работу SQL сервера, создав интенсивную нагрузку на дисковую подсистему сервера с помощью какой-нибудь специализированной программы, например, Performance Test или SQLIO. Во время выполнения теста попробуйте что-нибудь сделать на сервере. Как работается? Чувствуете, какое "торможение"? Это происходит из-за того, что тестирующая программа и операционная система используют для своих нужд один и тот же дисковый массив и мешают друг другу. Если не вынести интенсивную дисковую нагрузку на отдельные диски, операционная система либо совсем перестанет отвечать на запросы, либо будет работать очень медленно.
Надеюсь, Вы согласились, что файлы базы данных следует размещать отдельно от файлов операционной системы. Теперь зададимся вопросом, насколько рационально размещать файл данных (*.mdf) и файл транзакций (*.ldf) на одном дисковом массиве. Вспомним несколько особенностей работы SQL сервера:
- доступ к файлу данных преимущественно произвольный, т.е. в любой момент времени система может считывать и записывать самые разнообразные данные. Это приводит к тому, что головки жестких дисков постоянно перепозиционируются, а это приводит к замедлению операций ввода/вывода;
- доступ к файлу транзакций преимущественно последовательный, практически всегда в файл производится запись и лишь иногда чтение. Головки жестких дисков перемещаются в основном на соседние дорожки, что не занимает много времени;
- при внесении изменений в базу данных, эти изменения сначала фиксируются в файле транзакций, и лишь затем в файле данных во время очередной "chekpoint". Подробную информацию по работе с файлом транзакций можно получить из BOL по строке поиска "Write-Ahead Log".
Произвольный ввод-вывод, генерируемый для файла данных, будет мешать последовательной записи в файл транзакций, в целом снижая производительность подсистемы ввода вывода. Хорошим решением будет разнести эти файлы по разным массивам, т.е. выделить один RAID1 для файла данных и другой RAID1 для файла транзакций. Рекомендации Microsoft по поводу размещения файла транзакций можно узнать из BOL, строка поиска "Optimizing Transaction Log Performance".
Подведем итоги.
Нам необходимо 6 жестких дисков, организованных в 3 массива RAID1. Такое решение обеспечит надежность хранения данных, отказоустойчивость операционной системы и скорость обработки информации SQL сервером.
Если финансовые возможности позволяют, можно сделать SQL сервер еще более быстрым. Для этого надо вынести базу tempdb на отдельный диск или массив RAID0. Вот что говорится по этому поводу в BOL:
Рекомендации Microsoft по поводу настройки и размещения tempdb можно узнать из BOL, строка поиска "Optimizing tempdb Performance". Посмотрите также обсуждение этого вопроса на форуме www.sql.ru.
6 дисков - это тот необходимый минимум, который должен быть установлен на Вашем сервере. В процессе рабочей эксплуатации программы 1С может выясниться, что массив, на котором хранится файл данных (*.mdf), не успевает обрабатывать запросы. В этом случае Вам следует усилить дисковую подсистему:
- купить 2 или больше жестких дисков;
- вместо RAID1, на котором хранится файл данных, сделать RAID10 из 4, 6 и т.д. дисков
Если Вы наперед знаете, что нагрузка на диски будет большой, сразу купите не 6, а 8 или 10 дисков. Это избавит Вас от необходимости в будущем перестраивать массив из RAID1 в RAID10.
Я рекомендую размещать файл данных на массивах RAID10 или RAID1. Это самое дорогое, но в то же время самое надежное и быстрое решение (RAID0 не рассматривается, т.к. он не обеспечивает отказоустойчивости). RAID5 не подходит для работы с 1С, т.к. у него очень низкая скорость записи.
В заключение хочу дать еще один совет - создайте резерв из 2-3 винчестеров. Если вдруг что-то произойдет с жесткими дисками сервера, Вы сможете оперативно заменить их на исправные.
Предвижу Ваш вопрос - зачем такой большой резерв? В наше время характеристики жестких дисков меняются очень быстро, и новые модели приходят на смену старым. Может получиться так, что к тому моменту, когда на Вашем сервере выйдет из строя жесткий диск (например, через год), такие модели дисков уже не будут производиться.
В следующих статьях я расскажу Вам, как настроить этот сервер для работы с 1С.
Примечание: в статье отражено мое мнение по поводу выбора конфигурации для SQL сервера. Оно может не совпадать с Вашим мнением и / или мнением других специалистов.
Комментарии
1