Даже если сервер SQL, сервер 1С и клиенты 1С физически находятся на одной железяке - настраивайте их взаимодействие так, как будто они разнесены по разным серверам.
Теперь чуть-чуть подробнее.
Допустим, у нас есть один мощный свободный сервер и 5-7 пользователей 1С, для которых нужно организовать нормальную работу программы.
Пользователей немного, но через время ожидается их существенное увеличение, плюс будут выделены деньги на покупку новых серверов.
Но пока что - сервер один и всё надо сделать прямо сейчас.
То есть, смысл задачи понятен: настроить всё так, чтобы впоследствии безболезненно разнести разные серверные роли по разным железякам.
Наши пользователи будут работать в терминале.
Во первых, такое решение стабильнее.
Простая ситуация: заглючил свич. Или бухгалтер активно шевелил ногами под столом и выдернул с корнями сетевой провод (да, это бред - ставить системники под стол, но чаще всего так и бывает). Не важно.
Что происходит в случае, когда клиент 1С установлен на компьютере бухгалтера? Правильно - как минимум все несохранённые данные накрываются известным органом и в сторону системного администратора летит смачный кусок гуано.
В решении с терминалом такой проблемы нет, бухгалтеру достаточно переподключиться к серверу и продолжить с того места, на котором он остановился.
Во вторых, на рабочих местах могут быть не Windows, а другие операционные системы. И это две большие разницы - заставить 1С работать в «неродном» WINE или работать напрямую с сервера Windows, используя любой клиент RDP.
В-третьих, мощность рабочей станции несопоставима с мощностью сервера. Ресурсы сервера будут распределяться между всеми пользователями, ресурсоёмкие операции будут проходить быстрее.
Для определённости будем рассматривать только классическое Windows-решение.
Пользователей будет много, поэтому понадобится SQL-сервер, 1С-сервер (кластер серверов) и терминальный сервер с клиентской частью 1С.
Делаем на мощном сервере RAID5 (напоминаю, там будет SQL, которому критична высокая скорость чтения-записи).
Ставим Windows 2003/2008, называем сервер «srv», это имя не будет иметь значения.
Устанавливаем SQL, сервер 1С, клиент 1С и настраиваем роль терминального сервера.
Теперь самое интересное.
1. В DNS сети сопоставляем имена «sql», «1c» и «ts» ip-адресу нашего единственного сервера.
sql, 1с и ts - это выбранные имена для будущих выделенных серверов SQL, 1С и терминального сервера соответственно.
Таким образом, обратившись по любому из этих имён, мы попадём на сервер srv.
2. Настраиваем взаимодействие ролей и служб так, как будто они работают на физически разных железяках.
Например, 1С будет обращаться к SQL-серверу не на localhost, а по сетевому имени sql, и т.д.
3. Дописываем файл hosts на srv.
Чтобы не дёргать каждый раз сетевой DNS.
Файл %windir%\system32\drivers\etc\hosts:
... 127.0.0.1 sql 127.0.0.1 1c 127.0.0.1 ts ...
Если кто не знает, этот файл - локальный аналог DNS. Перед обращением к сетевому DNS соответствие имени с ip-адресом ищется именно здесь.
Кстати, этим активно пользуются вирусы, сопоставляя серверы для обновлений антивируса с адресом 127.0.0.1.
После этой процедуры, к примеру, сетевые SQL пакеты даже не будут попадать в локальную сеть, а будут сразу нагибаться на виртуальный интерфейс localhost.
4. Настраиваем терминальные клиенты пользователей на подключение к серверу ts.
<>127.0.0.1 sql <>
С остальными серверами - по аналогии.