Как правильнее использовать ресурсы ПК для терминального сервера и 1C+SQL?

Question

[Владимир Кивва]

Всем привет, уже несколько лет мой сервер для 1С и просто удалённых рабочих столов организован как гипервизор + виртуальные машины с ролями: файловика, 1С+SQL, шлюза и пары терминальников. Само железо имеет пару винтов nvme по 1TB (softraid) и пару вертушек по 4TB (hwraid). Из-за того, что многие базы 1С нельзя опубликовать в веб, приходится все серверы терминалов целиком держать на nvme-накопителе, т.к. 1С чувствительна к скорости временных файлов пользовательского профиля.

Как правильно сделать, чтобы куча файлов, которым не нужна скорость, не лежали на быстрых накопителях? Только storage spaces? Работает ли оно в моих условиях?

Answer 1

[АртемЪ]

Как правильнее использовать ресурсы ПК для терминального сервера и 1C+SQL?

Ну для начала - зачем виртуализация?
Виртуализация штука несомненно удобная, поэтому ее есть смысл использовать для удобства работы с инфраструктурой.
Но если на первом месте быстройдействие - есть смысл задуматься, нужна ли она вам.

Особенно проблем доставляют диски при виртуализации. Сразу забываем про такие удобные вещи как TRIM, и зачастую имеем кучу проблем с быстродействием.

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

А кто мешает вынести на быстрый диск только юзерпрофиль? Причем можно использовать физический диск примонтировав его к виртуалке.

Только storage spaces? Работает ли оно в моих условиях?

Работает. Ярусное хранение можно организовать. Но конкретно в вашем случае - когда можно отделить требовательные к скорости файлы явно, лучше так и сделать.

Ну и шлюз - он то тут каким боком? Обычно под это выгоднее выделить специальную железку.
Да и смесь файловых и SQL баз - почему файловые не закинуть на SQL сервер?

Comments

[Владимир Кивва]

Это в ДЦ, арендуется одна железка. Шлюз много делает, там pfsense, начиная от geoip, заканчивая всякими остальными блеклистами, фильтрациями, пробросами портов в разные виртуалки, т.к. разные терминальные серверы на железке, vpn и т.д.
Виртуализация оправдана, т.к. во-первых самой производительности хватает, во-вторых нужны снапшоты перед большими работами, в третьих она же даёт частично тестовую среду, плюс там пара мелких виртуалок для сайтов, сервера удалённого управления и т.д.

Домена нет, поэтому было бы тяжело перепрописывать каждому новому пользователю appdata на быстрый диск, а остальные директории оставлять на медленном. По крайней мере, раньше мне так казалось.

Физ-диск монтировать к виртуалке - не мой путь. Многим мелким виртуалкам хочется дать скорость винта. А если физ прокидывать в вирт, то прокидывать целиком оба диска в одну ВМ, т.к. без зеркала жизни не вижу. Тогда придётся прокидывать их только в SQL, а профили уже по сети монтировать.

Как это TRIM не работает в HV2019, когда диски напрямую без рейда подключены?

Значит буду пробовать SS, спасибо. Там вроде можно закреплять диски отдельно под винты, когда требуется, а остальное должна встроенная логика решить.

[rPman]

Владимир Кивва,

Как это TRIM не работает в HV2019, когда диски напрямую без рейда подключены?

пару винтов nvme по 1TB (softraid

плюс

виртуальные машины

Если внутрь виртуалки не пробрасывать весь контроллер с диском (или к примеру какой-нибудь iscsi/aoe настроить, на физические диски а не loop на основе файлов) то trim не будет работать. Я не знаю ни одну виртуальную машину/гипервизор, которые бы заявляли о поддержке ssd trim.

Если железки не совсем дубовые, то достаточно на дисках оставить свободными 10-30% (буквально пустой раздел, на который не будет записей, и разок там выполнить trim) то за оптимизацию распределения будет отвечать внутренний контроллер ssd дисков, и trim будет не актуален.

[АртемЪ]

Домена нет, поэтому было бы тяжело перепрописывать каждому новому пользователю appdata на быстрый диск, а остальные директории оставлять на медленном.

Ну так полностью папку Users на другой диск вынести и все дела.

без зеркала жизни не вижу

Ну если зеркало нужно - тут ничего не сделаешь.

Как это TRIM не работает в HV2019, когда диски напрямую без рейда подключены?

Как они напрямую подключены, если у вас виртуальная машина??? Если напрямую подключены будет работать. Если виртуализация - не будет.

[Владимир Кивва]

АртемЪ, напрямую в Гипер. В том плане, что без HW RIAD. Виртуалки с обычными VHD работают.

Решил проверить. Действительно из ВМ трима проверки говорят, что не работает.
Ищу способы как-то это запустить, хотя бы скриптом всякие punchzero.
Вроде бы заявляют, что если везде 2019 - то само должно, сделал тестовый стенд - само не работает.

[АртемЪ]

Владимир Кивва,

Виртуалки с обычными VHD работают.

Значит забудьте про TRIM - ну это же очевидно.

Ищу способы как-то это запустить

Это невозможно в принципе.

Физический диск подключайте к ОС - будет работать.
RAID контроллер - в большинстве случаев не будет работать, хотя теоретически возможны контроллеры где будет организованна корректная передача команды.

Если физический диск подключен к гипервизору - ну там вообще никак не реально запустить TRIM.

[Владимир Кивва]

АртемЪ, но ведь если диски тонкие, мы можем передать гиперу, когда место освбождается через sdelete с ключом -z, а дальше он проведёт trim, т.к. "увидит" освободившееся пространство?

[АртемЪ]

Владимир Кивва,

мы можем передать гиперу, когда место освбождается через sdelete с ключом -z

Это как?
sdelete это утилита для гарантированного удаления информации. Она записывает информацию.
С ключом -z насколько я помню она запишет нули.
И что дальше? Кому она что может передать? Каким образом она вдруг будет взаимодействовать с гипервизором? И какое это отношение имеет к TRIM?

Принцип работы TRIM - файловая система смотрит в своей базе данных карту свободного места - и отдает эту информацию диску - просто список LBA адресов. Вот и весь TRIM.

Гипервизор видит на диске файл виртуального диска, это обычный файл. И он занимает место.
Что там внутри файла ему неинтересно.
Ну запишите вы там нули - будет нули хранить, ему какая разница какую информацию хранить.

Answer 2

[rPman]

upd. не сообразил что сервер у тебя на windows, а мой ответ подходит только для linux хоста (можно конечно пробросить контроллеры дисков внутрь одной из виртуалок, и там уже на Linux все сделать но мне кажется это извращением)

уже не актуально

Если есть потребность хранить больше данных чем позволяют ssd, не терять в скорости и не управлять размещением данных вручную (а это бывает очень непросто если у тебя виртуалки, размазывать для каждой софтинке ее файлики в виртуалках по разным дискам это геморой, кстати не всегда возможный), то можно попробовать настроить кеширование медленных hdd дисков, разместив bcache кеш на ssd.

Делать это лучше, мне кажется, там где к дискам прямой аппаратный доступ (на гипервизоре или пробросив контроллеры в виртуалку которая файлсервер). Так же сначала на основе физических железок поднимаешь raid-ы, а уже на получившихся - поднимаешь bcache, поверх получившихся дисков поднимаешь хранилища, а уже там либо файлы виртуалок и/или сами раздавать файлы по сети.

Настоятельно рекомендую не делать один большой блочный bcache диск с одним большим кешем на все доступное пространство на ssd... лучше поделить на тома, соответственно с разным характером нагрузки. Причем размеры кешей для каждого характера нагрузки могут быть разными. А еще можно части ssd и hdd диска выделить для разделов вне кеширования.

Пример - если сделать 2 блочных устройства отдельно для файлов ОС (к примеру выделил всего 8гб кеша) и отдельно для файлов нагруженной базы данных (у меня так на очень слабой железке 2013 года, хорошо такие нюансы выявлять) то высокая нагрузка на базу данных не затронет кеш файловой системы ОС, характер нагрузки ОС отличается от базы данных, файлы ОС читаются и меняются редко, и если бы лежали на одном блочном устройстве, из ssd кеша их бы выкинуло быстро, а так - отзывчивость работы с ОС осталась на высоте при видимой высокой на hdd диск из-за базы данных.

p.s. если у тебя ssd диск в рейде, то не бойся включать bcache стратегию writeback, поднимает скорость очень заметно

Comments

[АртемЪ]

ответ подходит только для linux хоста

Почему? То же самое можно сделать и на windows.

[rPman]

АртемЪ, хм.
подскажи пожалуйста, каким софтом можно настроить ssd кеширование в windows?
я находил только привязанные к железу решения, плюс это не дешевое удовольствие

[АртемЪ]

rPman, Так стандартные Storage Spaces - они поддерживают ярусное хранение. Причем давно, уж лет шесть назад поддержка ярусного хранения появилась.
Оно конечно не кэширование в чистом виде, а именно ярусное хранение, но действует более эффективно.
https://habr.com/ru/post/541074/
А чистое кэширование - intel rapid storage, там привязка к железу есть, но работает на большинстве десктопных интеловских плат. Оно вообще давно появилось, как только первые SSD в широкую продажу пошли. Когда SSD были по 60 а то и 30гб - пользовался им на офисных компьютерах. Сейчас на домашних и офисных в нем особого смысла нет, поэтому в основном в серверных решениях используют.

[rPman]

хм, Покопаюсь, спасибо

не ожидал что жто будет доступно в не серверных релизах win