Да, есть такая возможность.
У 1С есть такой объект в конфигураторе "Web Сервис". но на стороне сервера 1С должен стоять Apache или IIS. Она (1С) прописывает свою Dll в Веб сервер и Имя вебсервиса с путем к базе данных. Ты посылаешь запрос на вебсервер (Например Localhost/myDB/PostOrder), у него (Вебсервера) в конфиге прописано - обращаться на нужую Dll, Dll пересылает запрос на конкретную базу, а там конекретный вебсервис (По имени входа), а там уже процедура и дальше код 1С ... с возвратом или без .. по желанию.
Больше информации гуглится по "1с веб сервис пример"

Вручную, базы для 1С обычно не создаются по нескольким причинам.
Одна из основных - структура таблиц, (в т.ч. имена полей и таблиц) должна быть в точности как 1С планируется её использовать. (Имена таблиц, далее будут записаны в соответствие, в отдельной таблице)
Также после создания , эта структура бд, должна быть в опр. виде в двоичных данных в нескольких "Служебных таблицах", в точности воссоздать которую - дело крайне проблематичное.
Если у вас есть желание создавать базы скриптом, самый простой способ - создать "пустышку" из 1С, создать бэкап, а далее его разворачивать там, где вам необходимо.
З.Ы.: даже пустая база, созданная из 1С, по факту будет не пустой, в ней будет куча служебных данных. Именно поэтому, ваша база выдала ошибку при подключении к кластеру (не были обнаружены, служебные данные в служебных таблицах)

1. Загрузить процессор на MSSQL можно так :
- Должна быть задача на SQL серваке, которая потребует этих ресурсов (в простое или при малых задачах SQL проц не загрузит)
- Ставим параллелизм = количеству ядер
- Ставим Стоимостной порог в 0.
После завершения текущих проверок, советую вернуть MAXDOP/MaxThreshhold на (1/4 или 1/8 от количества ядер а порог выявить методом проб и замеров). Дело в том, что загрузка проца 100% не значит что всё будет быстрее (только в некоторых случаях типа проверки целостности). Т.к. при распараллеливании запросов по ядрам, появляются "Накладные расходы" на распараллеливание и сбор обратно результатов воедино. Это будет выглядеть как ожидания CXPACKET и Latch. (См "закон Амадала" + CXPACKET в гугле)
2. "Проверка целостности базы данных" - на ежедневной основе смысла не имеет, особенно если база достаточно крупная. Её имеет смысл делать или при возникновении проблем, или раз в квартал/месяц ... зависит от размеров базы.
3. Если есть проблемы с производительностью, это вопрос не простой, и требует кучу опыта. Навскидку рекомендую сначала проверить :
- Нагрузку на дисковую подсистему, и если там будет проблема (Очередь к диску более 2 в среднем) выполнить разнесение *.mdf, *.log, tempdb, инстанс кластера 1c серверов на отдельные диски.
- Нагрузку на оперативку от MSSQL (можете гуглить это может вызывать большую активность IO на дисковую подсистему)
- Проверить способ коннекта к MSSQL ("Shared memory" должно быть "on" и использоваться, если 1с сервак и mssql сервак физически на одно машине .. это +10% к производительности.
ну и куча чего ещё ... в одном посте всего не расписать.
и т.д. вариантов очень много.
главный совет: решайте проблемы , только если она есть и мешает, если это лично ваше мнение, а пользователям не мешает, лучше делайте настройки по дефолту (см. APDEX, анализ производительности)
UPD: И да, виртуалки для 1C + MSSQL = зло, и не потому что "фирма 1С плохая", а потому что у вас не сможет 1С и MSSQL не сможет общаться через оперативку, и между оператором чтения на MSSQL до железа сервера будет 4 прослойки (SQLOS, OS виртуалки, Гипервизор, OS сервера, вместо SQLOS + OS сервера).