athacker

3. Сайт -- он для того и сайт, чтобы давать AD понимание структуры вашей сети. От этого будут зависеть параметры репликации, и, например, такие вещи, как выбор контроллера для авторизации. Если вы сделаете один сайт, то у вас пользователи из филиала могут авторизоваться на "головном" контроллере, или на любом контроллере из другого филиала. Т.е. авторизация пойдёт по WAN-каналам, и будет занимать соответствующее время.

Поэтому по фэншую нужно делать так, как сейчас у вас сделано -- каждый филиал со своим контроллером -- это отдельный сайт.

Да, и "главность" DC в нынешней структуре AD -- понятие достаточно условное, сейчас все контроллеры равноправны. Разница может быть только в наличии/отсутствии ролей или глобального каталога на конкретном DC, а в остальном все равны.

Деньги поступят на внутренний счёт. Не знаю, как насчёт пионера, у меня был привязан аккаунт PayPal. Деньги будут 6 дней находиться в режиме pending, т.е. они вроде как есть, а вроде сделать с ними ничего не можешь :-) В течение этого периода у клиента есть возможность оспорить платёж. Если работа по фиксированной цене, то клиент ручками переводит тебе сумму. Если почасовая ставка -- деньги со счёта клиента могут сниматься автоматически, раз в неделю.

Вот, а потом с внутреннего счёта можешь вывести наружу, например, на PayPal. Но это тоже какое-то время занимает, точно не помню, какое. Дней 5, что ли? Короче, от момента выплаты тебе денег клиентом до их получения на карту может пройти около двух недель.

Юрикам проще работать с юриками, чем с физиками. Поэтому наличие ИП существенно расширяет выбор потенциальных клиентов. К тому же, регистрация ИП не очень сложна, и также даёт профит в виде полностью белых доходов. 6% налогов с дохода + платежи в ПФР, и вы чисты перед законом :-)

У некоторых вендоров есть различные варианты nic teaming. В том числе и такие, которые используют поддержку на коммутаторе. У Broadcom есть такое -- ставится специальный софт и собирает серверные адаптеры в team. Такое же есть и у Intel. Но это реализуется только на определённых моделях сетевушек отдельных производителей. Если у вас самосбор -- вряд ли удастся что-то забалансировать.

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

Поэтому нужно оценивать тип трафика, который у вас через этот сервер гоняется, чтобы понять, как конкретно его можно балансировать. Возможно, c помощью одного сервера это нельзя сделать вообще, и нужен будет кластер из серверов. Так как, например, если вы расчитываете, что объединив интерфейсы в некий тим, получите скорость отдачи файла по SMB в 2 гигабита для одного конкретного клиента, то так не будет. LACP использует хэш на основе MAC-адресов, и пакеты конкретного клиента всегда будут приходить и уходить через конкретный сетевой интерфейс.

VPN -- это общее название целой пачки технологий и протоколов. Там есть и OpenVPN, и IPsec, и GRE, и PPTP/L2TP, и ещё всякие.

Ничего другого для связки двух сетей пока ещё не придумали, только VPN :-) Согласен с ораторами выше -- нужно разбираться, почему падает соединение. А тактика таких разборок будет зависеть от того, какой конкретно протокол для реализации VPN у вас использовался. Возможно, проблема в провайдере, возможно -- в вашем оконечном оборудовании, т.е. роутерах или серверах, на которых у вас этот VPN реализован.

Конечно, права должны быть обрезаны по максимуму. Если скрипту для выполнения хватает юзерских прав, то надо запускать под юзером. Если же какие-то нужны действия от рута -- то всё равно запускаем под юзером, а эти действия делаем через sudo :-)

Локальные диски всяко быстрее будут работать, чем отданные по iSCSI. Если есть желание повозиться с iSCSI, то это спокойно можно сделать и на виртуальных машинах. А чтобы не плодить хосты -- NAS также можно поднять в виртуалке. Тогда вы обходитесь одним хостом -- на нём ESX, а внутри уже всё остальное, включая NAS.

bin result in struct bintime containing seconds and 64-bit fractions of seconds.
nano result in struct timespec containing seconds and nanoseconds

Так что похоже, что конвертировать-то можно, но с потерей точности.