Jump to content
XPEnology Community

mrrc

Member
  • Posts

    86
  • Joined

  • Last visited

Everything posted by mrrc

  1. Не, не привередничаю) Как раз-таки простота и унификация базовых подготовительных действий подразумевает отсутствие необходимости танцев с бубном, направленных предоставить интернет загрузчику для возможности автоматизации выполнения сборки. Сценарий с DHCP применим не всегда же по месту.
  2. К данному пункту изначально и обратился, но был удивлен отсутствием в нем возможности полноценно настроить сетевые настройки подключения. Там задаются только ip\mask, но конфигуратору загрузчика для сборки нужен доступ в интернет..
  3. Arc удивил, столь юзабилити приятный во всех отношениях загрузчик заставил спотыкнуться на пустом месте. Маршрут и днс задал через командную строку загрузчика. ip route add 0.0.0.0 via static_ip_address vi /etc/resolv.conf
  4. Парни, так я не ошибся и не нашел, а в ARCe действительно в конфигураторе не задать сетевые настройки статикой для возможности сборки\дальнейшей настройки DSM. Да ладно?
  5. Что-то растерялся. При отсутствии DHCP при конфигурировании загрузчика где задается шлюз\днс? Для ip\mask есть соответствующий раздел, но он не содержит требуемых значений.
  6. Создал для тестирования сценарий пока в едином сетевом сегменте, правда в качестве контроллера основного домена (RWDC) выступает станция с 2012R2 с DNS, в дополнение к ней поднят Synology Directory Server в роли RODC и DNS сервером. В общем и целом схема понятна, развернута и частично работает, учетки пользователей синхронизируются между RWDC и RODC, за исключением главного. Пользователи и их пароли не реплицируются на RODC, когда прописываем их в группе с запрещением\разрешением репликации паролей RODC как разрешенные. Ни при первичной авторизации, ни при ручном добавлении через оснастку расширенных политик репликаций паролей на RWDC. Результурующая политика также отрабатывается правильно по учетке разрешенного на предыдущем шаге пользователя. Бьюсь и не могу понять, где моя ошибка. Соответственно если "ложится" основной контроллер домена с 2012R2, то у win-клиент с доменной учеткой утрачивает доступ к хранилкам, подключенным к домену, в т.ч. и на которой развернут сам RODC. ДНС при этом работает, доменные хосты резолвятся и серверы пересылки отрабатывают внешний мир, но т.к. сохраненных пользовательских учеток и их хешей паролей на RODC в одноименном разделе оснастки "Учетные записи, пароли которых хранятся на данном контроллере домена только для чтения" (там появились только комп с win-клиентом, сам RODC, krbtgt_12726 пользователь и дополнительная хранилка, включенная в домен) нет, но обращение висит или сразу вываливается с ошибкой. У клиента в качестве основного DNS первым идет RODC (можно и RWDC, не суть). После "оживления" основного контроллера все приходит в норму.
  7. Ну вот видите сколь полезный и немассовый по примененному решению положительный опыт. А разворачивание схемы DC под Windows в роли RWDC и сопряжение с Synology Directory Server в роли RODC (быть может, наоборот) возможно у кого-то имелся? В части подводных камней и нюансов настройки.
  8. В продолжении ранее затронутой темы в одном из топиков по реализации домена с территориально разнесенной инфраструктурой, когда пользователи могли бы мигрировать между офисами и использовать свои доменные учетные записи для авторизации на АРМах, поступило предложение вынести этот вопрос в отдельную одноименную тему на случай, если кому-то обсуждение окажется полезным и будет что дополнить. Будем считать для порядка и для практики (на практике так скорее всего и будет), что хотя бы в одном из офисов DC работает на базе Synology\Xpenology в виде развернутой на ней виртуальной среде или в виде приложения Synology Directory Server. Сценарий из практики. Имелся "главный офис" с работающим RWDC (Read Write Domain Controller), инфраструктура разрастается, сформировался территориально удаленное производство, временный канал связи между ними поднят, и туда постепенно перебираются "АРМ-ы" из главного офиса, ранее уже включенные в домен (работоспособность по месту имеется, первичный ДНС основного DC им доступен на АРМах, доменные учетки работают, хоть там пока и слабоватый канал связи между офисами) и ставятся новые пока без вхождения в домен. Пользователи периодически могут мигрировать между офисами. Нужно принимать решение, как действовать в части поддержания доменной инфраструктуры на обеих площадках или отказа от нее в удаленной агломерации. Для отказоустойчивости среды передачи данных по имеющейся апробированной практике поднимается RODC (Read Only Domain Controller) в удаленном офисе для обслуживания тамошних пользователей как дополнение к основному. В общем уважаемому @XPEH возможно будет чем поделиться по существу и мне сейчас этот сценарий интересен, если появятся практические затыки в реализации.
  9. Видимо на одном из этапов процедуры восстановления "Системы полностью"..
  10. Схожий сценарий с одним из моим теперешних объектов. А от не доменных учеток, заведенных локально на АРМах в разных офисах, в которых подцеплены сетевые папки требуемые пользователю, отказались? Просто домен с территориально разнесенной инфраструктурой площадок пока все еще вызывает осторожность у меня.
  11. А какие средства резервного копирования позволят нам с вами сделать подобное избирательное восстановление?
  12. Да, это вроде рабочий вариант и вы вот его подтверждаете положительным опытом применения. А как решали повторным перенавешиванием прав пользователей по доступу к общим папкам или необходимость благо не возникала?
  13. Да, с учетом наличия двух как раз поддерживаемых HA девайсов в виде RS1619xs+ будем по итогу смотреть в эту сторону. Но одно другого не исключает, поэтому интересны все варианты по теме. На самом деле, HA возможен ну далеко не всегда по понятным причинам и тему поднял для общего понимания по вариативности решений, упрощающих и ускоряющих действия по восстановлению работоспособности в случае нештатных ситуаций. По итогу пока приходим к тому, что приложений, умеющих гибко работать по миграции базы заведенных пользователей не находится, а встроенный Export/import, который как минимум позволил бы развернуть имевшиеся аккаунты пользователей в новой среде по факту не работает как задумано?
  14. Не, посмотрел внимательнее в ключе вопроса, не обнаружил обсуждаемого функционала в С2. Это бэкап\восстановление в облако (весьма тормознутое) с определенными опциями. Может не обнаружил очевидного, конечно, но меня бы уже давно поправили, я думаю. Отчасти то, про что говорим, это функционал встроенного функционала Export/import пользователей в одноименном разделе конфигурации. Это хотя бы тот минимум, который позволил бы переносить целиком учетки пользователей, ну а распределение прав к папкам общего доступа следующий ручной этап. Экспорт по умолчанию в html\cvs, но принимающий аналогичный по dsm девайс не дает возможности принять данные, и не совсем очевидно, переносятся ли пароли списка пользователей. Кто-нибудь разобрался с этой возможностью?
  15. Да я бы сказал самая обыденная, подобный механизм предполагался мною если не в базе, то за счет расширенного функционала приложений, в том же функционале репликаций общий папок и механизме аварийного переключения\развертывания на другой устройстве. Гляну вечером, в ссылке от @dj_nsk на одном из скринов присутствует файл user_account, вроде же в С2 шла речь про гибкие возможности. Только сомневаюсь, что можно взять такой архив с учетками накатить на новую локацию с восстановлением всех взаимосвязей в части прав доступа к развернутым общим папкам))
  16. Это несколько иное, для территориально распределенных потребителей в виде Hybrid Share. Ну выйти с вопросом и ТЗ нужно же как-то для обвязки вопроса, применительно к реализациям сени.
  17. Облачную их хранилку я не пробовал, у вас имелся опыт в ключе вопроса? Если гибкость решения позволит выполнить резервирование данных аккаунтов с их привязкой по правам доступа к общим папкам, то да. Но в любом случае, бэкап объемов самих данных общих папок в облако не предполагается в принципе в наше непростое время.
  18. Выполнять репликации данных общих папок на территориально удаленное устройство, имея возможность оперативно "поменять" источник с целевым сервером местами, выполнив переключение. Удобно, понятно, прозрачно. Но, как быть с пользователями и их правами доступа к реплицируемым общим папкам, они то не передаются при репликациях и переключении источник\целевой сервер. Если их три, ладно, а если тридцать? Отдельного инструмента, который бы умел сепаратно выполнять именно этот важный элемент резервирования и восстановления общей работоспособности NAS как NAS я не нахожу. Либо систему\пакеты\данные целиком, либо какие-то их составляющие, но базу пользователей системы с привязкой по правам доступа к общим папкам решения нет?
  19. А, ну да, там речь про ESXi ведется, у вас же проксмокс, верно. На счет вашего отказа от варианта использовать ESXi я так и не понял все же, VMware не рекомендует использовать USB-флешки и SD-карты для загрузочных устройств. У вас же недурные NVMe M.2 накопители.
  20. Ага, читал про это. Но с другой стороны, не обязательно на ESXi 8.х переходить, к которой эти рекомендации относятся. Тогда вопрос, на что же тогда платформу ставить? Носители NVME инсталлятор актуальных сборок ESXi тоже не воспринимает как должный дистинейшен? Как же они так с родным то девайсом обошлись, вроде же проприетарный аксессуар как раз под означенные цели. А контроллер с дисками в виртуалку с DSM по этим предписаниям отдаете?
  21. Саму платформу вы развернули на один из этих NVME, я так понимаю и система видит этот массив 4*2 как четыре независимых диска? А 4*6TB HDD это уже непосредственно хранилища плюсом.
  22. Кстати, proxmox позволяет сделать программный рейд на всех софтверных\фейк контроллерах линейки микросерверов, начиная с Gen8? Просто смотрю вы выбрали его, а не ESXi, который такое точно не поддерживает и уважает только дискретный адаптер под эти цели.
  23. А поясните, зачем четыре NVME-диска такого объема? В Gen10+ для установки платформы виртуализации (а такое железо именно под виртуализацию и берется в основном) из коробки нет "пятого" SATA-порта или MicroSD и выручает единственная PCI-e шина на борту под адаптер. Ведь процитированная конструкция в 100К примерно выходит помимо самого проапгрейденного девайса.
  24. +Тепловыделение еще, поэтому и заострил внимание на вашем i9-9900t с 35W, для микро форм-фактора это немаловажный атрибут. Кстати, на счет 64Gb, платформа G10+ разве поддерживает 2х32Gb? Везде значится up to 32Gb вроде ж, нет? Один из факторов против покупки Gen8 на максималках в качестве основного микросервера для развертывания на нем под эксплуатацию на постоянной основе ряда систем + лабораторные задачи, как раз ограничение ОЗУ в 16Gb, это порог, который постоянно может о себе напоминать.
  25. Это уж прямо козырно как то очень в плане TDP. Даже Xeon E3-1265L V2 под Gen8 с его TDP 45 обходит. Ну и раз мы говорим про microserver для квартиры\домовладения, как по вашим наблюдениям он в части энергоэффективности и шумности, пишут он шумнее Gen7\Gen8 просто в режиме простоя.
×
×
  • Create New...