Доброго времени суток!
Помогите в распределении файлов SQL по дискам и OS двух VM.
MS SQL 2019.
На сервере 1 диск NVMe 1.7 Tb, 4 диска SSD/HDD(вариативно). На физическом сервере 2 VM, одна 1с сервер приложений, вторая MS SQL.
Бэкапы могут хранится на стороннем сервере.
Видится сейчас 3 варианта:
1 вариант:
1 SSD это VM 1с
2 SSD это OS MS SQL, бэкапы делать сюда же, потом перемещать.
3 SSD это файлы баз данных
4 SSD это файлы журналов
NVMe это TempDB
2 вариант:
1 SSD это VM 1с
2 SSD это OS MS SQL
NVMe это TempDB, файлы баз данных и файлы журналов
2 HDD в рейде, бэкапы делать сюда, потом перемещать только полные, остальное оставлять тут.
3 вариант:
1 SSD это VM 1с
2 SSD это OS MS SQL, файлы баз данных
NVMe это TempDB и файлы журналов
2 HDD в рейде, бэкапы делать сюда, потом перемещать только полные, остальное оставлять тут.
Как оптимальнее всего расположить файлы? Если можете предложить более оптимальным вариант, буду рад ознакомится.
Помогите в распределении файлов SQL по дискам и OS двух VM.
MS SQL 2019.
На сервере 1 диск NVMe 1.7 Tb, 4 диска SSD/HDD(вариативно). На физическом сервере 2 VM, одна 1с сервер приложений, вторая MS SQL.
Бэкапы могут хранится на стороннем сервере.
Видится сейчас 3 варианта:
1 вариант:
1 SSD это VM 1с
2 SSD это OS MS SQL, бэкапы делать сюда же, потом перемещать.
3 SSD это файлы баз данных
4 SSD это файлы журналов
NVMe это TempDB
2 вариант:
1 SSD это VM 1с
2 SSD это OS MS SQL
NVMe это TempDB, файлы баз данных и файлы журналов
2 HDD в рейде, бэкапы делать сюда, потом перемещать только полные, остальное оставлять тут.
3 вариант:
1 SSD это VM 1с
2 SSD это OS MS SQL, файлы баз данных
NVMe это TempDB и файлы журналов
2 HDD в рейде, бэкапы делать сюда, потом перемещать только полные, остальное оставлять тут.
Как оптимальнее всего расположить файлы? Если можете предложить более оптимальным вариант, буду рад ознакомится.
По теме из базы знаний
- Особенности работы платформы 1С с СУБД OracleDatabase
- Настройка PostgreSQL для работы в связке с 1С 8.х на платформе Windows Server 2012, объём БД более 200 Гб
- Разработка и сценарное тестирование с Vanessa-ADD. Практические примеры сценариев. Шаги встроенной библиотеки
- Парсер технологического журнала (golang + redis + elasticsearch)
- "Обновление через копию" - как это использовать?
Найденные решения
(5) Ну тогда вариант выше.
Как уже писал сами VM не требуют большую дисковую производительность и можно их положить на HDD.
NVMe:
Из VM 1С вынести рабочий каталог сервера (srvinfo) и каталог временных файлов сервера (по умолчанию temp пользователя от которого запущен 1С).
Из VM MS SQL каталог Data с системными базами, TempDB и журналы баз.
SSD:
Сами базы MS SQL.
В зависимости от версии MS SQL можно использовать сжатие баз, это уменьшает дисковую нагрузку, размер баз и несколько увеличивает нагрузку на процессор.
Как уже писал сами VM не требуют большую дисковую производительность и можно их положить на HDD.
NVMe:
Из VM 1С вынести рабочий каталог сервера (srvinfo) и каталог временных файлов сервера (по умолчанию temp пользователя от которого запущен 1С).
Из VM MS SQL каталог Data с системными базами, TempDB и журналы баз.
SSD:
Сами базы MS SQL.
В зависимости от версии MS SQL можно использовать сжатие баз, это уменьшает дисковую нагрузку, размер баз и несколько увеличивает нагрузку на процессор.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Сразу возникает вопрос: зачем городить огород с VM? Не проще поставить сразу на сервер?
Сами VM вполне нормально будет жить на HDD рейде, вместе с основной ОС, надо только подумать о выносе рабочих каталогов сервера 1С. NVMe - TempDB, файлы журналов БД, рабочие каталоги сервера 1С. Сами файлы БД на SSD.
Сами VM вполне нормально будет жить на HDD рейде, вместе с основной ОС, надо только подумать о выносе рабочих каталогов сервера 1С. NVMe - TempDB, файлы журналов БД, рабочие каталоги сервера 1С. Сами файлы БД на SSD.
(5) Ну тогда вариант выше.
Как уже писал сами VM не требуют большую дисковую производительность и можно их положить на HDD.
NVMe:
Из VM 1С вынести рабочий каталог сервера (srvinfo) и каталог временных файлов сервера (по умолчанию temp пользователя от которого запущен 1С).
Из VM MS SQL каталог Data с системными базами, TempDB и журналы баз.
SSD:
Сами базы MS SQL.
В зависимости от версии MS SQL можно использовать сжатие баз, это уменьшает дисковую нагрузку, размер баз и несколько увеличивает нагрузку на процессор.
Как уже писал сами VM не требуют большую дисковую производительность и можно их положить на HDD.
NVMe:
Из VM 1С вынести рабочий каталог сервера (srvinfo) и каталог временных файлов сервера (по умолчанию temp пользователя от которого запущен 1С).
Из VM MS SQL каталог Data с системными базами, TempDB и журналы баз.
SSD:
Сами базы MS SQL.
В зависимости от версии MS SQL можно использовать сжатие баз, это уменьшает дисковую нагрузку, размер баз и несколько увеличивает нагрузку на процессор.
(7) Это нужно проанализировать как их будут использовать. Если например будут приложены сканы договоров, которые один раз прикладывают и потом раз в сто лет смотрят, то самого медленного хранилища хватит выше крыши.
Т.е.: Надо проанализировать какие объемы и с какой частотой будут читаться и писаться. В обычном случае HDD вполне достаточно. Если очень интенсивное использование присоединенных файлов, то максимум SSD.
Еще если исходить из исходных данных, то видимо кроме NVMe, все диски выделяются на большом хранилище? Тогда производительности и HDD может хватать.
Т.е.: Надо проанализировать какие объемы и с какой частотой будут читаться и писаться. В обычном случае HDD вполне достаточно. Если очень интенсивное использование присоединенных файлов, то максимум SSD.
Еще если исходить из исходных данных, то видимо кроме NVMe, все диски выделяются на большом хранилище? Тогда производительности и HDD может хватать.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот