• Какую структуру домена Active directory использовать?

    ifaustrue
    @ifaustrue
    Пишу интересное в теллеграмм канале @cooladmin
    В моей практике я использую такие принципы:
    Про АД и службы
    1. В головном офисе два контроллера домена с низкими задержками в репликации.
    2. В полно-связных офисах с широкими каналами по полноценному контроллеру домена
    3. В удалённых офисах, с низко скоростными линками по одному RoDC
    4. Те офисы, что не имеют в распоряжении сервера - либо остаются без домена, либо как то работают (живут в отдельной OU с щадящими параметрами жизни сессий и ДНС).
    5. Каждый офис всегда в своём сегменте сети. Каждый сегмент - отдельный сайт в AD
    6. DHCP+DNS виндовые, если это не вызывает конфликтов и возможно использовать. WINS скорее полезен чем нет. Создавайте обратные зоны ДНС они ускоряют.
    7. Разное оборудование \ VoIP \ WiFi \ Принтеры \ Проекторы \ Свичи - по возможности, в отдельных сегментах

    Теперь побольше про сети
    Заранее определите хотя бы намётки адресации. Старайтесь не использовать распространённые домашние диапазоны, но придерживайтесь рекомендованных адресов (10/8, 172.16/12, 192.168/16)
    Принципы такие
    1. Одно отказоустойчивое маршрутизирующее ядро на площадку. Старайтесь весь трафф замыкать в одну точку. Точку эту резервируйте (в вашем случае VRRP плюс статья на хабре)
    2. Там где можно, линки идут LACP \ дублем \ вторым маршрутом \ двумя GRE-туннелями
    3. Меньше бриджей - больше маршрутизации. По возможности, только транзитные сети, никаких l2 переходов.
    4. По возможности, в одном сегменте оборудование одного класса \ типа \ предназначения \ уровня доступа.
    5. WiFi и VoIP всегда в отдельном сегменте.

    Теперь чуть конкретики для вас.
    Начните с адресации, т.к. если не наладите движение трафика связность сайтов у вас опять потеряется и будете огребать с этим до конца дней.
    Наладьте маршрутизацию (благо железо позволяет), а потом переходите к AD (если последнее, конечно, не горит).
    Для связности офисов используйте IPSec в транспортном, а не туннельном режиме (потом мне ещё не раз спасибо скажете).
    Офисов у вас уже прилично, можно попробовать поднять RIP или OSPF (в вашем случае я за первый вариант, но если у вас есть множественная связность между офисами, то он не подойдёт).
    В принципе у вас нет никаких предпосылок городить лес Доменов или домены второго уровня. Всё отлично будет жить в одном домене в разных (хотя и это не обязательно, можно всё настроить на основании сайтов) OU.

    По отказоустойчивости - я выше уже написал, ничего нового изобретать не нужно - два АД с быстрой репликацией, два DHCP с разделёнными областями, два DNS - вполне себе ок (для параноиков можно юзать 3 АД, но имхо это перебор для 300+ машин).
    По миграции данных - планируйте постепенный переход.
    1. Подняли Новый АД, подняли новые сети и раздаёте их по DHCP, в них все параметры на новые шлюзы и DNS
    2. В новом ДНС сделали ссылку на старые домены - это позволит старью работать, а новым не иметь проблем.
    3. Машина за машиной переводите их в новый домен, заводите пользователей, профили юзверей просто копируете (мигриуете) исправляя права пользователей на папки в профиле. Не напрягаясь можно по 50 машин в день переводить.

    Если будут вопросы - можете мне стукнуть в скайп.
    Ответ написан
    Комментировать
  • Как защититься от сис.админа и программиста, храня секретные данные в БД?

    Данные о зарплате заводятся в проект наверное не только для того, чтобы там храниться, но и как-то участвуют в вычислениях.
    Поэтому если у Вас трехзвенка, то защититься от админа сервера приложений невозможно - данные должны быть там в дешифрованном виде.
    Если же есть возможность работу над этими "высокосекретными" данными всю производить по двухзвенной схеме - в клиентском браузере, то тогда - да, шифрование с должными предосторожностями (с рандомизацией и защитой от replay attack) Вас в принципе спасет. Хотя задача всё равно будет нетривиальной.

    P.S. Кстати, Вы уверены, что ставку нельзя будет "вычислить обратно", зная сумму оплаты за этап и его трудозатраты в часах ?
    Ответ написан
    Комментировать
  • Как реализовать сетевой рендеринг в Active Directory?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Именно так сделать невозможно, но если рендерер может запускаться в фоне, то просто запускайте его через планировщик в нужное время от имени нужного пользователя и ограничивайте максимальное время выполнения задачи.
    Ответ написан
    1 комментарий
  • Как искать по xml?

    mlnkv
    @mlnkv
    JavaScript Developer
    Комментировать
  • Какой выбрать процессор под сервер Intel Xeon Ivy Bridge?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Если пользователи будут работать прямо на сервере в терминальном режиме - то важнее количество ядер, если на сервере будет только сервер приложений 1С - то гигагерцы.
    Ответ написан
    3 комментария
  • Какую CMS выбрать для одностраничного сайта?

    ZeLib0ba
    @ZeLib0ba
    [IT]ишник | http://surin.ru
    Использую get-simple.info
    Ответ написан
    Комментировать
  • Какова будет оптимальная структура таблиц в моем случае?

    fornit1917
    @fornit1917
    Аттачи в отдельной таблице и присоединять по id записи или как-то иначе?


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

    Хэштеги также отдельной таблицей или лучше простым перечислением в отдельной строке таблицы самой записи.


    Отдельной таблицей, с индексом по хэштегу. Если в поле TEXT перечислением их указывать, то не сможете эффективно поиск по хэштегам делать. В MySQL правда есть полнотекстовые индексы, но не рекомендую их использовать.
    Ответ написан
    Комментировать