Vladimir Zhurkin

Да используются и 3.5
Почему в общем нет ?

Тут уже на вариант или 2.5 или 3.5 И зависит от задач.
Просто по плотности выгоднее брать все же 2.5 , с учетом raid итд итп.

Кто сталкивался/собирал: как себя ведет массив созданный в Linux средствами mdadm и LVM2?
Видел в доках redhat-а рекомендации по такой реализации.

Можно посмотреть на такие доки RH, где дают вредные советы ?

Т.е. берем 4 диска и собираем два зеркала с помощью mdadm, а потом с помощью LVM2 создаем поверх этих массивов единый том. По структуре - RAID10, но по реализации не совсем он.

В LVM2 RAID0 плюс только один, это создание снепшотов и добавление новых HDD.
Только вот чтение и запись будет у такого решение последовательно и в общем прибавки скорости не светит.
Второй момент, что надежность в случаи отказа такой схемы спорная. У вас по факту может вылетить 1 диск или 2 диска из разных массивов. восстанавливать такой слоенный пирог не очень удобно, в случаи проблем - восстановление может быть квестом. Поэтому проще делать все на mdadm сразу например.

Как будет работать в вариантах диски HDD и диски SSD?

Да в общем как обычно. Отличий минимально.

Для каких задач это будет хорошее решение, а для каких - плохое?

Тут нет ответов и не будет. Все решается бенчмарками и от самих задач. При этом бенчмарки сугубо под ваши нужды и под ваше железо.
Но я бы вообще ушел и от mdadm и от lvm и уже смотрел на ZFS с его плюшками. Там вам уже и LVM, и Raid и снепшоты и кеширование итд итп. В ближайшие время ФС будит доминировать. Можно настроить два уровня кеша. Память->SSD- и уже все на HDD.

А как это делают современные люди? Может можно обернуть эти сервисы в docker контейнеры? Или засунуть в виртуалки? Или так не делают?

Делают кто- как привык. Но чаще уже все в контейнерах lxc,docker или просто kvm машина.
Проще переносить на новую машину, проще делать разворачивание системы через ansible,chef итд.
Проще следить и выделять ресурсы, а не когда машина встала колом из-за определенного сервиса.
Я да же на своей машине все раскидываю по контейнерам.

Просто прежде чем все засунуть в Docker, очень рекомендую ознакомится с концепцией его работы и как он хранить данные и как работает image у него. Возможно такое вам не подойдет и вы будите использовать lxc.

moosefs не использую, но беглый взгляд по документации дал понимание, что уменьшить или увеличить интервал нельзя.
Есть рекомендация в промежутки интервала делать копию метаданных любым удобным способом.

Yes, it is highly recommended to make additional backup of the metadata file. This provides a
worst case recovery option if, for some reason, the metalogger data is not useable for restoring
the master server (for example the metalogger server is also destroyed).
The master server flushes metadata kept in RAM to the metadata.mfs.back binary file every
hour on the hour (xx:00). So a good time to copy the metadata file is every hour on the half
hour (30 minutes after the dump). This would limit the amount of data loss to about 1.5h of
data. Backing up the file can be done using any conventional method of copying the metadata
file – cp, scp, rsync, etc.
After restoring the system based on this backed up metadata file the most recently created files
will have been lost. Additionally files, that were appended to, would have their previous size,
86
which they had at the time of the metadata backup. Files that were deleted would exist again.
And files that were renamed or moved would be back to their previous names (and locations).
But still you would have all of data for the files created in the X past years before the crash
occurred.
In MooseFS Pro version, master followers flush metadata from RAM to the hard disk once an
hour. The leader master downloads saved metadata from followers once a day.

https://moosefs.com/Content/Downloads/moosefs-user...
www.it-recipes.com/articles/blog/122

> Кластер из 2 серваков. С подобным не сталкивался, насколько возможно с моим бюджетом собрать производительное решение?

Кластер из двух серверов это не оптимально. Должен быть кворум. (те три)
Для кластера необходимо еще и СХД и тогда точка отказа будет эта самая СХД.
Это конечно самый правильный вариант был бы делать кластер, но очень дорого.
Клиентов по своему опыту, хорошо загонять в терминальные сессии. Тут надо смотреть насколько нагружается сеть 1С и насколько все тормозит.
SSD+hdd лучше использовать в гибрид по технологии storage space, там же можно и raid сделать программный.
Вполне работоспособная вещь.

В итоге я наверно бы сделал так, а многие тут покрутят у виска и скажут что я псих и полно потери производительности. Но с вашими 50 человек и больше это мелочи.

Взять хороший сервер. Под систему взять диски 256gb в кол-ве трех. Сделать зеркало + hot spare.
Остальное добить SSD+HDD из расчета , что примерно на 1 tb данных, лучше взять 256gb кеша SSD. (хотя бы).
Используя Microsoft StorageSpace сделать Raid+кеширование.
SSD лучше взять из расчета на зеркало.
Создать две машины виртуализации на Hyper-V. Зачем ?
1) Удобнее делать backup целой машины сразу
2) Если все умрет, вам проще будет развернуть эти машины где угодно, просто их перетащит куда надо.
3) Если вдруг вы упретесь в производительность, можно легко это все разнести и кластеризировать.
У вас не те нагрузки, что бы например создавать отдельный ClusterFileSystem (там правда могут храниться только MSSQL и машины Hyper-V)

Бюджет правда не очень понятно, это на сервера с лицен ?

Как уже выше сказали любой сервер. Но еще подскажу, что как вариант взять сервер 1u и к нему jbod корзину.
Использовать в качестве OS Windows и ее технологию Storage spaces. Можно и без корзины и все сделать в одном корпусе, это уже как захочется. Там можно будет формировать диски как душе угодно, тут лучше просто почитать.
В состав этого всего можно включить и SSD как диск кеша для всего массива, что увеличить общий iops в приделах кеша. Итого получится два винта в raid для самого сервера + один под hot swap. 1 или больше ssd и нужное вам кол-во винтов.

Вопросы собственно в следующем:
-Какое железо подобрать?
-Какое ПО использовать для Firewall и резервного копирования
-Как не потерять OEM лицензии windows на машинках (Реально ли делать полный бекап образа диска и потом его развернуть обратно?)

Без фанатизма на 15 человек взять

mikrotik в качестве головы готовое решение из серии 2011
https://routerboard.com/RB2011iL-IN
или не намного дороже 3011
https://routerboard.com/RB3011UiAS-RM

В качестве switch однозначно новый crs326. В теории он и на 15 человек справится с выходом за NAT, но это плохая практика из switch использовать как роутер. Хотя он может, если только на первое время. (но мы же помнем, что временное оно как бы постоянно ;) )

Для NAS взять готовый qnap/synology опять же бывают неплохие варианты БУ на барахолках. Если бюджет совсем минимален, я бы использовал вариант с nas4free.
https://www.nas4free.org/
Да на BSD, но web морда делает свое дело и в общем ползать в консоли и править конфиги не особенно нужно. Можно одну машину как ФП в сети, вторую как backup.
Осилите связку zfs+l2arc будет очень быстро работать. Для кеша hdd можно использовать как память так и в совокупности с памятью ssd начиная от 64gb.
RAID я в общем сделал бы на том же ZFS. Хороший аппаратный стоит дорого, а от дешевого больше проблем чем пользы.

Для OEM резервных копий в общем и не надо. Сейчас обычно активация вся идет через SLIC bios.

Тут нет четкого ответа, могут быть только рекомендации.
Все сильно зависит от того, насколько плотно будут использоваться виртуальные машины/контейнеры.
В вашем варианте, я бы использовал контейнеры, так как плотность контейнеров и нагрузка на машину минимально. Можно рассматривать разные варианты от openvz/lxd/docker , до коммерческих продуктов типа proxmox/virtuozzo и наверно kubernetes , но он больше для разработчиков.

Файловую систему лучше использовать ZFS , если речь не идет о коммерческих продуктах (исключение proxmox).
Это даст возможности Raid, кеш дисковый подсистемы L2. Те можно будет использовать часть памяти как кеш, далее идет как кеш SSD и уже обычные HDD. Надо понимать, что лучше купить много памяти и это все имеет смысл, если будут частые обращение к файловой подсистеме. Но это будет лучший вариант, чем под каждую виртуальную машину SSD (в экономических целях)

По поводу 1000 подключений одновременно, они бывают разные и могут вызывать разную нагрузку. Как видите тут нет четкого ответа, можно только провести тесты.