Странно. При подключении хоть с linux, хоть с win 11, интерфейс в rdp сессии должен быть один.
Проверить можно просто подключившись под другим пользователем (у которого интерфейс другой по вашему мнению)
Сегодня на этом ядре крутится один сервер, а завтра 5 серверов на этом же ядре :)
Сегодня для теста дали нагрузить проц, а завтра придушат производительность при нагрузке.
Это сложно тестить и прогнозировать, потому что не контролируется со стороны пользователя.
bit8, для бэкапа обычно не требуется такой-же сервер.
Потому что бэкапы могут храниться на дисках медленных. То есть если под рабочие данные выделен R10 из SSD (потеря 50% емкости), то под бэкапы обычно можно R60 из HDD (потеря 30% емкости или менее, но итоговую емкость нужно больше чем начальных данных, чтобы хранить больше копий).
И железка под бэкапы не должна быть высокопроизводительной, как рабочий сервер.
Но все индивидуально...
yuda_wd, диски классные. Но информации о защите кеша я в спецификации не нахожу. Прямым текстом не написано что кеши защищены.
Хотя есть Advanced Write Caching (Internal NOR flash)... но там и dram есть наверняка.
yuda_wd, если у контроллера есть батарейка, то можно включить write back вместо write through. Заработает кеш на контроллере.
Если диски не крутые энтерпрайз, то у них нет своей защиты кеша. Значит нужно выключать это кеширование, оно опасно. Модель дисков не указали, так что гадать остается.
ответом на вопрос будет - использование динамических дисков. Не помню было ли ограничение на применение динамических дисков к системным разделам, но вроде нет.
Правильный ответ на вопрос - нельзя так делать. Можно все лишнее (раздел D) скинуть на новый ssd и расширить диск c на освободившееся пространство. При этом нужно будет загружаться с live cd и использовать спец утилиты, потому что там в середине странный раздел 690м, возможно имеющий отношение к загрузке.
Но раз уж использовать загрузку с live cd и утилиты, то почему бы просто не скопировать с маленького диска на большой все как есть, просто увеличив разделы?
BlinCT, если будет 4 диска по 16 тб, то емкость вы получите 32 тб. Уйдет 50% емкости. В этом случае проще R10, оно почти такое же по надежности, но значительно быстрее. В R6 емкость двух дисков уходит, их интересно собирать если носителей от 6-7 шт.
При 16Tb можно попрощаться мысленно с данными в R5. Слишком велики шансы сбоя во время ребилда. Ну то есть, может и повезет. Но надо понимать что риски высоки и просто смириться с этим.
inneks если вы собираете raid из SSD, то убедитесь что либо SSD мегакрутые, либо этот чипсет у интела прямо поддерживает trim в raid режиме. Уже попадал на такую проблему. Диски убивались за год.
Drno , возможно. Сколько не вынимал диски с софтовых виндовых рейдов зеркальных (и аппаратных тоже), всегда данные можно было просто считать.
Drno, возможно у вас попался какой-то очень специфический чипсет. Во времена W7 все уже так же работало.
Софтовый рейд силами винды на системном диске.. Ну не знаю. Оно обычно не дает нормально грузить при сбое одного диска. Или если у одного из дисков много бедов он все равно будет пытаться грузиться с него. Он не переключится на второй, это уже проходили.
Если собирать не системные диски, то там да, чисто софтовый у винды сейчас отличный вариант.
можно. И через прокси и через любой ваш файрвол.
На прокси/файрволе просто даете доступ ко всяким там сайтам MS типа catalog... Есть у мс где-то список ресурсов которые нужны для обновлений.
Сдается мне что вы не полностью задачу озвучили.
Дмитрий, тогда у вас нет вариантов кроме как R10. То есть потери половины емкости. И то может не хватить.
Ведь R10 из 12 дисков это по сути, если я правильно помню, по скорости 6 дисков обычных. Представили как работает сервер на одном обычном диске (не ссд) по скорости? Вот тут на 6 таких не очень быстрых дисков приходится 10 серверов.
И будет еще пенальти на файловую систему кластерную, и на сеть.
Если у вас там сервера которые просто файлопомойки, то хватит производительности. Если там есть БД, то сразу ищите способы докупить SSD.
10G не всегда поднимаются в режиме хост-хост. Может потребоваться коммутатор, учтите эти затраты. Кроме того, серверам для нормального общения друг между другом тоже потребуется сеть. Можно и 10г.
BlinCT, посмотрите сетевые карты и главное - коммутаторы на 2,5G. Есть вероятность что передумаете по поводу 2,5. Выбор 2,5 резко сужает выбор оборудования и повышает бюджет. Там до 10G ethernet по цене недалеко.
ИБП должен быть с выходами для подключения - usb|rs232. Ну и должна быть хоть какая-то информация о совместимости с системой на которой вы собираете. Обычно есть информация о совместимости. ИБП можно и потом докупить.
Возможности расширения емкости зависят от того чем именно и какой именно рейд соберете. Если это зеркало, то расширить его можно будет как минимум двумя такими же дисками. Если R5, то можно диски докидывать обычно. Но опять же - смотрим чем собираем и читаем мануал. Но тут возникает новая проблема - R5 не рекомендуется для емких дисков (4тб и более), т.к. очень большое время ребилда. Так что приходим к R6, а это уже много дисков и потеря емкости (на 4 дисках 50% емкости в трубу)... Короче - для домашнего R5 и ставим свечку )
Saboteur, добавлять диски что в lvm/zfs , что в mdadm будет проблематично. Есть риски и там и там нажать что-нить не так. Системы NAS типа Truenas вроде умеют это делать через красивый гуй, с минимальными требованиями к квалификации юзера.
информация теряется обычно при пересборке raid'а аппаратного, если у аппаратного рейда нет функции расширения емкости без потери данных. А она обычно сейчас везде есть, но может не хватить гибкости. Например raid5 можно будет диск добавить, но перейти с raid5 на R6 уже никак без полного разрушения.
BlinCT, так то мысль хорошая. Если бюджет позволяет.
- 2,5 гигабитные коммутаторы уже есть или просто в планах?
- кеш при чтении фильма не поможет, т.к. чтение все равно будет с медленного диска. Вот на запись кеш может помочь.
- на такую хранилку было бы неплохо накатить plex или jellyfin.
- ОС и приложения лучше на ssd ставить. И уже программным рейдом собирать массив из hdd.
- сейчас странная ситуация. Стоимость hdd улетает в космос, а ssd дешевеют. Возможно, уже можно собирать массивы Raid 5 из емких SSD бытовых. Скорость в разы выше, деньги почти те же, надежность выше если учесть что hdd - SMR. Это если данные большую часть времени просто лежат и не перезаписываются постоянно.
Уже посоветовали freenas/truenas - поддержу.
Можно еще навернуть ZFS (она позволит кеширование, дедупликацию), но будет значительно сложнее, требования к железу выше и ломучесть... Наверное оно того не стоит под видосики.
Saboteur, Synology/QNAP NAS не включает в себя аппаратных raid контроллеров. По крайней мере те модели которые мне попадались. И корп версии тоже включают в себя обычно HBA, то есть решение построено на программном рейде.
Но работает из коробки и не нужно ничего выдумывать, настраивать, читать, мучать себя.
inneks, там есть megaraid CLI и megaraid storage manager GUI.
CLI - консольные инструменты. Можно при большом желании ограничиться этим. Но графический интерфейс конечно визуально удобнее.
В readme указаны требования для установки. Версия java тоже должна быть указана.
Уж имя прежнее точно не стоит оставлять. Можно потом огрести всяких неудобств в виде останков от старого DC в каталоге и непонятно будет это от старого или от нового.
Если по варианту 2, то убедитесь что есть прям самые новые и хорошие бэкапы DC и что их можно быстро развернуть если что. Так-то вероятность потерять единственный DC за несколько часов что поднимается новый - крайне низкая.
Проверить можно просто подключившись под другим пользователем (у которого интерфейс другой по вашему мнению)