chernilschik: это смотря что вам дороже. Один бэд может остаться на диске навечно, а может привести к тому, что через пару дней у вас высыпется весь диск.
chernilschik: выход очень простой -- не использовать диски с бэдами. ZFS тоже не будет делать remap, но будет стараться обеспечить целостность данных -- если какой-то блок с диска она не сможет прочитать, то вытащит этот блок с другого диска и запишет его на сбойный диск в другое место. Таким образом, данные будут целыми и совпадать на двух дисках зеркала. Но это, понятное дело, работать будет только до определённого предела, если диски посыпятся сильно, то есть риск, что им уже ничего не поможет.
kondrash055: а в чём проблема выделить каждому юзеру отдельную виртуалку? Если вам нужен брокер -- тогда вам всё-таки нужно какое-то решение VDI. Можно, конечно, наколхозить своё подобие брокера и я не вижу особого смысла в этом. Просто если вы заявили, что "хочется каждому пользователю дать свою виртуалку", и тут брокер скорее вреден, чем полезен -- у вас на каждой виртуалке будет лежать куча профилей тех пользователей, которые брокер на неё смаршрутизировал, что будет приводить к повышенному использованию дискового пространства. Надо ли оно?
VDI в полном объёме интересен со всеми своими плюшками -- golden image, виртуалки по требованию, автоматическое прибивание неиспользуемых виртуалок и т. п. Тогда надо выбирать именно VDI решение, и уже оно будет диктовать выбор гипервизора.
kondrash055: Лицензирование -- это самый мутный путь в этих вопросах :-) В принципе, у вас обычные рабочие станции, так что нужны лицензионные винды. Если использовать RDP, то с лицензией не ниже Professional, так как в более младших версий нет RDP-сервера. С другой стороны, так как вы хотите AD, то вам по-любому придётся не ниже Professional покупать, так как только они (и старше) могут быть включены в домен.
Есть ещё такой момент -- если развернуть гипервизор на честно купленном Windows Server Standard, то это даёт вам ещё две лицензии на виртуальные Windows-сервера. Т.е. каждая лицензия на физический Windows Server Standard даёт +2 лицензии на Windows Server виртуальный. А Windows Server Datacenter Edition даёт вообще неограниченное количество лицензий на виртуальные windows-сервера внутри себя :-) Бесплатный Hyper-V Server дополнительных лицензий не даёт, т.е. каждую копию виртуальной винды нужно будет лицензировать отдельно.
Про SPICE ничего не знаю, никогда не использовал, но есть обоснованное мнение, что для винды лучше родного RDP ещё ничего не придумали. Совместный буфер обмена, включая перегонку файлов, маппинг каталогов/принтеров, проброс звука, all that jazz...
Что касается "беготни до каждого пользователя" -- не вижу необходимости. Если у вас уже есть AD (или планируется) -- ну положите каждому юзеру на стол RDP-ярлычок, и разошлите им почту сообщение, типа:
1) у вас там на рабочем столе появилась картинка;
2) тыкаем в неё;
3) заходим в виртуальную рабочую станцию;
4) ...
5) PROFIT!
Что касается СХД для бэкапов, то выделять целую СХД под бэкапы -- это, на мой взгляд, малость жирно... Хотя, если у вас там СХД куры не клюют, тогда да :-) На бэкапы я бы поставил что-нибудь типа такого: https://www.supermicro.com/products/system/4U/6048... Ну или взять пачку серверов с корзинками поменьше (по 8, например) и собрать из них storage-кластер на базе какой-нибудь распределённой ФС (ну или даже той же самой ScaleIO). Один сервер с большой корзиной -- это сильно проще и дешевле, но зато распределённые ФС масштабировать в разы проще. Надо добавить объёмы -- добавил ещё один узел с дисками, и у тебя автоматом место расширилось. А в случае одного сервера если надо место расширить, то придётся менять диски, причём куча возни ещё будет зависеть от того, как у вас там дисковый пул собран. Если все диски в один пул, то надо менять ВСЕ диски, а если несколько пулов, то надо менять все диски в пуле, но несколько пулов -- это неудобно, так как постоянно ситуация, когда есть три дисковых пула, на каждом по 2 Тб свободно, а записать надо 5 Тб, ну и всякое такое в том же духе.
zorgingyaringen: А, да, про разные сети. Разные IP-подсети делайте, и будет вам щастье. При желании, конечно, в Hyper-V можно машины в разных сетях и более мощно изолировать -- создать несколько виртуальных коммутаторов в режиме private, когда виртуалки, подключенные к этому коммутатору, имеют доступ только к друг другу и никуда больше. Ну и роутеры между сетями, соответственно, должны иметь интерфейсы, подключенные к нескольким такого рода коммутаторам.
zorgingyaringen: организовать её можно на чём угодно. Хоть VMware, хоть KVM, хоть виртуалбокс, хоть Hyper-V. С точки зрения дальнейшего использование -- лучше брать Hyper-V Server или VMware, только не Workstation, а полноценный ESXi. Потому как в рабочей среде Workstation или VirtualBox вряд ли кто-то пользуется.
Hyper-V, кстати, начиная с Win8 встроенный есть ;-)
Ресурсы нужны будут, да. Особенно на Exchange, он очень до памяти прожорлив. Хотя если есть SSD, то памяти можно ему поменьше выделить, он будет приемлимо на SSD шевелиться. Остальное особых ресурсов не требуется. FreeBSD без ZFS можно и на 256 Мб оперативы запускать. Процессор перечисленные сервисы особо нагружать не будут. Windows Server для контроллера домена можно ставить в режиме core, тогда ему достаточно будет гигабайта оперативки. Процессор -- ну, какой-нибудь Core Duo, наверное, будет минимально достаточен. Quad или тем более i3-5-7 -- уже более чем достаточно. У вас же не производственная среда будет, нагрузки на эти сервера никакой особо не будет.
В общем, 12-16 Гб оперативы достаточно должно быть, и процессор -- от CoreDuo и выше. Можно SSD или RAID0 собрать под виртуалки из двух винтов поменьше, но в принципе, всё это не обязательно. Если виртуалки будут тупить, ничего, кроме вашего терпения, не пострадает, вам разгневанные юзеры звонить и клевать мозг не будут :-)
maxt888: Да на хабре вообще довольно странная аудитория в это отношении. Чуть только что в новостях про Россию, так разговоры: "Пора заводить трактор и валить из этой %$(*@#% страны!" А тех, кто дерзнёт заявить, что в "цивилизованных странах" всё то же самое (а то и ещё хуже), начинают немедленно массово минусовать.
Vi: при классической схеме организации виртуализации инфраструктура делится на три части: вычисления (т. е. собственно гипервизоры), сеть -- коммутаторы и пр., и хранилище -- СХД или NAS или любые иные виды.
При конвергентной структуре у нас выпадает необходимость в СХД как в отдельной сущности. А при гипер-конвергетной структуре -- ещё и в отдельных коммутаторах :-)
Конвергентная система -- это такая система, где вычислительные узлы также являются поставщиками устройств хранения. Т.е. одни и те же сервера крутят и виртуалки, и они же в разных видах размещают эти виртуалки на своих дисках, в масштабируемом, зарезервированном и безопасном виде.
У нас используется ScaleIO в тестовом кластере VMware. В каждом узле стоит по 4 диска, в ESXi установлен драйвер, и на каждом хосте крутится виртуалка ScaleIO, в которую напрямую проброшен дисковый контроллер. И все эти виртуалки делают так, что из дисков, воткнутых в хосты виртуализации мы получаем 13-терабатное хранилище с резервированием и возможностью линейного роста -- добавили ещё один узел, наторкали туда ещё дисков, на узел накатили ESXi, развернули ещё одну ScaleIO-шную виртуалку, и у нас появился одновременно ещё один узел виртуализации и заодно расширилось дисковое пространство в кластере.
Azazel PW: Товарищ, кто ясно мыслит -- у того нет проблем ни с дистрибутивами, ни с выбором ОС :-) На заре винды говорили -- "Зачем нужна ваша винда на серверах? Сравните аудиторию Netware и Windows". И где та Netware теперь? Так что размеры аудитории -- это не показатель. Netflix использует фрю, Juniper использует фрю, TrueNAS использует фрю. Вы же не считаете их инженеров и разработчиков глупее себя? Или всё-таки считаете? :-)
Что касается "разбавить фряхой". Вас кто-то заставляет иметь зоопарк систем в инфраструктуре? Если все ваши задачи решаются линуксом -- да бога ради. Но это не повод хоронить фрю :-)
Пума Тайланд: я реально считаю, что безопасность -- это комплекс мероприятий. В который входят как генерация ключей на вход и сложные пароли, так и перенос портов. Не очень понимаю, почему у вас в голове это стало взаимоисключающими параметрами.
Пума Тайланд: как я уже сказал выше, перевешивание SSH на нестандартный порт делает количество попыток подбора пароля статистически незначимым. В то время как на стандартном количество таких попыток исчисляются минимум сотнями в день.
