Переход с файловой версии на клиент-сервер. Подскажите, с чего начать.
Всем доброго времени суток. Никогда не задумывался над вопросом, указанном в заголовке, но тут понимаю, что надо. Ситуация: Бухгалтерия, стандартная "восьмерка", растет не по дням, а по часам. Файловый вариант, как мне кажется, не подходит к базе с количеством пользователей примерно 20. Подскажите, пожалуйста, с чего начать изучение процесса перевода, на какие ПО обратить внимание и какие ошибки могут возникнуть. Заранее спасибо :)
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Сначала надо определиться, какая операционная система и какая СУБД будут на сервере и как будут подключаться пользователи.
А "стандартная восьмерка" - это 8.0? А конфигурация какая? Надо подробнее знать что уже есть и что вы хотите, чтобы что-то советовать...
А "стандартная восьмерка" - это 8.0? А конфигурация какая? Надо подробнее знать что уже есть и что вы хотите, чтобы что-то советовать...
(15) planod, рекомендую RAID 1+0, под систему коло 100Гб, остальное по своему усмотрению. С твоими запросами все (и mdf и ldf файлы) можно разместить на одном массиве.
И памяти 12Гиг в принципе хватит, но учитывая сегодня цену на память - бери больше пригодится.
И памяти 12Гиг в принципе хватит, но учитывая сегодня цену на память - бери больше пригодится.
Начни с железа. 12 гигов памяти - это не много. и при правельной настройке sql заберет много свободной.
мой расклад
Win 2008 x64 + MSSQL 2008x64 +1c 8.2.16.368 x64 + WS X79 + Xeon 2620 + 64 ОЗУ 1600 + SSD 120 + 20 работающих тел + ут 10.3 6 гигов + бух 2гига при работе только SQL отжирает от 14 до 25 гигов оперативки, пиковую нагрузку на ОЗУ в момент заливки 5 баз одновременно видел 33 гига. Спокойная работа - 20 гигов ОЗУ на SQL.
Но, эти же люди с этими же базами спокойно сидят на
1 Win 2008 x64 + MSSQL 2008x64 +1c 8.2.16.368 x86 + p5b + core2Duo 7500 + 8 ОЗУ 800 + SSD 120 работает очень прилично, но комп на предельной нагрузке. и с ростом баз я думаю опечалится.
2 Debian 6.0.5 + Postgres 9.1.2 x64 + 8.2.14.540 x64 на этом же железе с этими же базами тоже нормально работает.
Это к размышлению платить или не платить за софт.
мой расклад
Win 2008 x64 + MSSQL 2008x64 +1c 8.2.16.368 x64 + WS X79 + Xeon 2620 + 64 ОЗУ 1600 + SSD 120 + 20 работающих тел + ут 10.3 6 гигов + бух 2гига при работе только SQL отжирает от 14 до 25 гигов оперативки, пиковую нагрузку на ОЗУ в момент заливки 5 баз одновременно видел 33 гига. Спокойная работа - 20 гигов ОЗУ на SQL.
Но, эти же люди с этими же базами спокойно сидят на
1 Win 2008 x64 + MSSQL 2008x64 +1c 8.2.16.368 x86 + p5b + core2Duo 7500 + 8 ОЗУ 800 + SSD 120 работает очень прилично, но комп на предельной нагрузке. и с ростом баз я думаю опечалится.
2 Debian 6.0.5 + Postgres 9.1.2 x64 + 8.2.14.540 x64 на этом же железе с этими же базами тоже нормально работает.
Это к размышлению платить или не платить за софт.
По дисковой подсистеме, вместо RAID 1+0 сделайте RAID 5(три винчестера) либо 6(четыре винчестера), имхо так надежней будет, желательно на отдельном (не встроенном в мат. плату контроллере), ОЗУ смотрите по размеру своей базы, если база 4 ГБ то 12 ОЗУ с верхом, а если 40 - то докупать))
По серверу 1с:
1)Нужно определиться с типом защиты сервера - ключ хасп или программная лицензия
2)Определиться с количеством процессов сервера - ПМСМ для вашего количества пользователей хватит и одного-двух, в любом случае делать их более чем процессоров на серваке смысла не имеет.
3)Настроить перезапуск процессов сервера(у меня делается раз в сутки)
По серверу баз данных
1) Определиться с выбором СУБД.
2) Разобраться с лицензированием СУБД - после этого получится стоимость покупки СУБД.
3) Нужно озаботиться выполнение регламентированных процедур сервера БД (для микрософта это "обновление статистики", "очистка процедурного кэша", "обновление индексов"(у меня - раз в день), "перестройка индексов"(раз в неделю)) тут фишка в том что некоторые процедуры могут выполняться и без выгона пользователей из базы а некоторые - нет.
4) Разобраться с тонкостями настройки выбранного сервера - ну там разнести на разные физические диски служебные и рабочие базы сервера и т.д. - тут гуглить по настройкам конкретного сервака под 1с. И не стоит думать что и по умолчанию все хорошо - кто даст гарантию что завтра у Вас не прибавиться еще пяток баз? Перестраивать систему "по живому" - тот еще экстрим.
После всего
Настраиваете систему бэкапов - 1с рекомендует делать бэкапы как с помощью сервера БД так и стандартной выгрузкой в режиме конфигуратора. Понятно что данная система должна работать автоматически? Мало того - нужно убедиться что она корректно работает и Вы сумеете при необходимости развернуть базу из любого бэкапа.
Если будете делать бэкап только выгрузкой базы из конфигуратора то нужно будет регулярно проверять эти выгрузки на "загружаемость" - то есть банально загрузится ли из выгрузки тестовая база без проблем или нет(у меня рабочий день с этого начинается). На выбор системы бэкапирования влияет размер базы(выгрузка может работать просто неприлично долго - если скажем база гигов 200, или если база работает в режиме 24/7 - то выгрузка тоже не подойдет и придется ограничиваться только сервером БД, в свою очередь бэкапы только сервером БД тоже не очень удобны - для получения базы для экспериментов добавляется лишний шаг). Для того чтобы убедится что это все работает - я загружал на будущий сервак базы из бэкапов и гонял их по разному - обновлял, перепроводил документы и т.д..
Перед часом Х
Убедившись что вся система работает(все регламенты выполняются) и ничего не падает через час после загрузки.
1) Убедитесь что после перезагрузки сервака доступ в базы сохранился - есть такая болезнь у сервера 1с. Выглядит так что все удачно запустилось а сервер 1с сервера БД не видит, хотя до перезагрузки все было в порядке и доступ в базы был. Но стоит вручную перезапустит службу сервера 1с и вуаля - все работает. Лечится сменой типа запуска службы сервера 1с на "автоматический(отложенный)" а если и это не помогает то запуск сервера 1с осуществляется через планировщик заданий сервака.
2) Согласовываете с бухами дату переезда
Час Х
1) Переводите у всех пользователей списки баз на файлы ссылок на иб - это когда путь к базе описывается через файлик в общей папке.(Внимание - не во всех релизах платформы это работает! Надо проверять!)
2)Выполняете ТИИ базы. Правите что можно.
3)Достаете бубен и ложите на стол рядом(это опционально)
4)Выгружаете и загружаете базу на сервер
5)Заменяете файлик общей ссылки на файловую базу на файлик общей ссылки на серверную - у всех автоматом поменяется путь к базе.(это объясняет зачем нужен п.1)
6)Старую базу блокируете на доступ - тут выявятся те пользователи у которых в списке баз вручную прописана старая база. Ну тут понятно что делать, да?
Вот и все.
ПЫ.СЫ Бубен вернуть на место не забудьте :-D
1)Нужно определиться с типом защиты сервера - ключ хасп или программная лицензия
2)Определиться с количеством процессов сервера - ПМСМ для вашего количества пользователей хватит и одного-двух, в любом случае делать их более чем процессоров на серваке смысла не имеет.
3)Настроить перезапуск процессов сервера(у меня делается раз в сутки)
По серверу баз данных
1) Определиться с выбором СУБД.
2) Разобраться с лицензированием СУБД - после этого получится стоимость покупки СУБД.
3) Нужно озаботиться выполнение регламентированных процедур сервера БД (для микрософта это "обновление статистики", "очистка процедурного кэша", "обновление индексов"(у меня - раз в день), "перестройка индексов"(раз в неделю)) тут фишка в том что некоторые процедуры могут выполняться и без выгона пользователей из базы а некоторые - нет.
4) Разобраться с тонкостями настройки выбранного сервера - ну там разнести на разные физические диски служебные и рабочие базы сервера и т.д. - тут гуглить по настройкам конкретного сервака под 1с. И не стоит думать что и по умолчанию все хорошо - кто даст гарантию что завтра у Вас не прибавиться еще пяток баз? Перестраивать систему "по живому" - тот еще экстрим.
После всего
Настраиваете систему бэкапов - 1с рекомендует делать бэкапы как с помощью сервера БД так и стандартной выгрузкой в режиме конфигуратора. Понятно что данная система должна работать автоматически? Мало того - нужно убедиться что она корректно работает и Вы сумеете при необходимости развернуть базу из любого бэкапа.
Если будете делать бэкап только выгрузкой базы из конфигуратора то нужно будет регулярно проверять эти выгрузки на "загружаемость" - то есть банально загрузится ли из выгрузки тестовая база без проблем или нет(у меня рабочий день с этого начинается). На выбор системы бэкапирования влияет размер базы(выгрузка может работать просто неприлично долго - если скажем база гигов 200, или если база работает в режиме 24/7 - то выгрузка тоже не подойдет и придется ограничиваться только сервером БД, в свою очередь бэкапы только сервером БД тоже не очень удобны - для получения базы для экспериментов добавляется лишний шаг). Для того чтобы убедится что это все работает - я загружал на будущий сервак базы из бэкапов и гонял их по разному - обновлял, перепроводил документы и т.д..
Перед часом Х
Убедившись что вся система работает(все регламенты выполняются) и ничего не падает через час после загрузки.
1) Убедитесь что после перезагрузки сервака доступ в базы сохранился - есть такая болезнь у сервера 1с. Выглядит так что все удачно запустилось а сервер 1с сервера БД не видит, хотя до перезагрузки все было в порядке и доступ в базы был. Но стоит вручную перезапустит службу сервера 1с и вуаля - все работает. Лечится сменой типа запуска службы сервера 1с на "автоматический(отложенный)" а если и это не помогает то запуск сервера 1с осуществляется через планировщик заданий сервака.
2) Согласовываете с бухами дату переезда
Час Х
1) Переводите у всех пользователей списки баз на файлы ссылок на иб - это когда путь к базе описывается через файлик в общей папке.(Внимание - не во всех релизах платформы это работает! Надо проверять!)
2)Выполняете ТИИ базы. Правите что можно.
3)Достаете бубен и ложите на стол рядом(это опционально)
4)Выгружаете и загружаете базу на сервер
5)Заменяете файлик общей ссылки на файловую базу на файлик общей ссылки на серверную - у всех автоматом поменяется путь к базе.(это объясняет зачем нужен п.1)
6)Старую базу блокируете на доступ - тут выявятся те пользователи у которых в списке баз вручную прописана старая база. Ну тут понятно что делать, да?
Вот и все.
ПЫ.СЫ Бубен вернуть на место не забудьте :-D
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот