Даже если сервер SQL, сервер 1С и клиенты 1С физически находятся на одной железяке - настраивайте их взаимодействие так, как будто они разнесены по разным серверам.

Теперь чуть-чуть подробнее.

---

Допустим, у нас есть один мощный свободный сервер и 5-7 пользователей 1С, для которых нужно организовать нормальную работу программы.
Пользователей немного, но через время ожидается их существенное увеличение, плюс будут выделены деньги на покупку новых серверов.
Но пока что - сервер один и всё надо сделать прямо сейчас.

То есть, смысл задачи понятен: настроить всё так, чтобы впоследствии безболезненно разнести разные серверные роли по разным железякам.

Наши пользователи будут работать в терминале.

Почему терминал

Во первых, такое решение стабильнее.
Простая ситуация: заглючил свич. Или бухгалтер активно шевелил ногами под столом и выдернул с корнями сетевой провод (да, это бред - ставить системники под стол, но чаще всего так и бывает). Не важно.

Что происходит в случае, когда клиент 1С установлен на компьютере бухгалтера? Правильно - как минимум все несохранённые данные накрываются известным органом и в сторону системного администратора летит смачный кусок гуано.
В решении с терминалом такой проблемы нет, бухгалтеру достаточно переподключиться к серверу и продолжить с того места, на котором он остановился.

Во вторых, на рабочих местах могут быть не Windows, а другие операционные системы. И это две большие разницы - заставить 1С работать в «неродном» WINE или работать напрямую с сервера Windows, используя любой клиент RDP.

В-третьих, мощность рабочей станции несопоставима с мощностью сервера. Ресурсы сервера будут распределяться между всеми пользователями, ресурсоёмкие операции будут проходить быстрее.

Выбор схемы работы 1С

Для определённости будем рассматривать только классическое 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.

Когда приедет новый сервер SQL

• Даём ему имя «sql», копируем базу с srv
• В DNS локальной сети изменяем A-запись для sql (ставим ip новой железяки вместо ip srv)
• На srv убираем из файла %windir%\system32\drivers\etc\hosts строчку:

  <>127.0.0.1	sql
  <>

С остальными серверами - по аналогии.