athacker

Два микротика-- это правильно, одобряю.

Сервер -- да, можно обойтись обычным десктопом, с корпусом, куда можно воткнуть 8 или более дисков. Только дисковый контроллер я бы посоветовал внешний. Например, LSI 9300-i8. Под фряхой работает ОК, я проверял. Дисковая конфигурация: RAID10, собирать ZFS-oм. То есть, потребуется минимум 4 диска в сервер, и как минимум один в ЗИП, всего пять. Диски обязательно хот-свопные -- можно будет менять на ходу, без остановки сервера.

Обязательно обновить прошивку контроллера -- у него была подлая бага, что при детаче на ходу одного диска он отсреливал сразу все диски. Данные не страдали, но ZFS-пул дох, разумеется. Лечилось только ребутом.

Есть один тонкий момент. Порт Самбы под BSD имеет косяки. По крайней мере, имел в версии 3.4, 3.5. При использовании файловой базы 1С более чем 2-3 пользователями одновременно резко просаживалась производительность. Это было связано с особенностями реализации блокировок открытых файлов, и насколько я помню, никак не лечилось. Возможно, в 4-ой версии это починили, но на момент моих исследований (года 4-5 назад) команда Самбы слала всех лесом, мотивируя это тем, что "у нас на линухе всё работает". Так что сначала надо протестировать производительность, перед вводом в прод. Чтобы потом не пришлось судорожно менять ОС.

Из железа ещё -- поищите БУ HP Proliant Microserver, 7 или 8-го поколений. Это отличные машинки, надёжные и с хотсвопными корзинками. И БУ они стоят недорого. Gen8 дороже, конечно, но тоже можно раскошелиться, там цены от 18 до 50 тысяч, в зависимости от комплектации. Gen8 лучше тем, что у них есть встроенный адаптер удалённого управления, с IPMI и IP-KVM. Дисковая корзина там на 4 диска, на 5-ый можно поставить систему. 5-ый ставится обычно в лоток от CD-ROM, есть специальные адаптеры, но можно и просто так положить. Только диск нужен будет 2.5". Дисковый адаптер туда тоже можно поставить, но только предыдущего поколения, т.е. LSI 9200 -- там (в сервере) SAS-разъём другой, к 9300-8i бэкплейн сервера не подключить.

Устройство для хранения бэкапов -- обязательно отдельное. Т.е. отдельный системник.

Готовые коробки типа QNAP/Synology -- это треш и угар, лучше даже не вязаться. Для дома ОК, для конторы -- нет. Максимум, что им можно доверить -- это хранение файлов бэкапов, и всё. Да и то, лично я бы не стал, больно много у них прибабахов.

Команда настройки iptables надо выполнять на виртуальном сервере, а не на домашнем компе :-)

Белые люди обычно делают наоборот -- свои мощности используют в основном, а чужие дата-центры -- как резерв на случай ядерной войны. Это первое.

Второе. Вы собрались 1С-ку по WAN-каналу реплицировать 1С. Сколько пользователей 1С-ки всего? 1, 10, 100?

Третье. vSphere для репликации, vMotion и других подобных операций требует задержек не более N ms. Проверьте, сможете ли вы выполнить сетевые требования на должном уровне. А то как бы не пришлось строить растянутые кластеры на гостевых технологиях (MS SQL, например, если база 1С в MS SQL).

Ну и 4-ое -- вообще непонятно, зачем для резерва выбирать сервер в другой стране, да ещё торчащий напрямую в интернет.

Никак. Вы можете выгрузить только список компьютеров, которые имеют учётки в AD. При этом статус этих компов (особенно "выключен") не сможете определить никак. Как вы себе представляете? Комп выключен, но при этом каким-то чудом сигнализирует в сеть: "чуваки, я выключен, меня не будить!"? :-)

В сети могут быть компы, не входящие в домен. Могут быть компы, где пинги закрыты файрволом. IP-адрес по дефолту микрософтовским DHCP выдаётся на 8 дней. Человек придёт из отпуска, включит комп, и комп получит уже другой IP.

"man vpn, Luke!" Читайте, что такое VPN вообще, и конкретные её реализации, в частности (например, протоколы IPSec, OpenVPN, L2TP). Почитайте про чудо-железки чудо-производителя Mikrotik -- они поддерживают все перечисленные, и ещё много разных других полезных протоколов.

На циске есть недокументированная утиля ttcp. Во фре есть в портах аналогичная утиля: /usr/ports/benchmarks/ttcp. По идее, должны работать вместе :-) Но оно там по дефолту всего 16 Мб для теста перегоняет, канал может не успеть раскачаться на полную. Есть сведения, что можно с параметром rcvwndsize поиграться, чтобы трафика больше прокачивало, но я с этим не работал, поэтому подтвердить не могу.

Как пинговали? По имени или IP-адресу? Если по имени -- имя резолвилось? Или не пинговалось из-за того, что имя сайта не резолвилось?

Трассировка от проблемных клиентов до сайта как идёт?

Респект за подробно описанную ситуацию :-) Всё ниасилил, но имею предложить следующее :-) У некоторых провайдеров (замечены Ростелеком, Онлайм) некорректно отрабатывает то ли cgnat, то ли какой-то ALG по дороге. Что приводит к блокированию НЕКОТОРЫХ типов пакетов в туннелях, либо при согласовании туннелей. У меня по этой схеме не устанавливаются L2TP сессии -- просто блочится определённый пакет в ответе клиента серверу, и всё.

Так я это всё к чему. Попробуйте поменять тип туннеля с проблемным IP. Либо попробуйте включить шифрование в этом туннеле, чтобы скрыть трафик. Возможно, тогда всё заработает.

К слову, HA -- это не отказоустойчивость, это высокая доступность. Отказоустойчивость -- это FT.

Если у вас сервис снаружи доступен, то только своя AS вам поможет. Либо полу-костыльный вариант, который реализует какой-нибудь Dyn -- при недоступности определённого IP меняет A-записи на резервный IP от другого вашего провайдера. А на роутере порт-маппингом или DNAT уже разруливаете, кого куды.

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

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

Возможна и обратная ситуация -- клиентов мало, но они ходят на кучу адресов (типичный вариант -- офисный интернет). Тогда LAG можно утилизировать В СУММЕ более полно. Но опять-таки, каждый клиент не получит больше скорости одного интерфейса. Так как пакеты одного соединения не размазываются на несколько интерфейсов.

Я бы, наверное, в такой ситуации настроил бы статически так, чтобы для каждого сервера его оба партнёра были доступны через выделенный интерфейс. Т.е.:

- сервер1 -- подключается к серверу2 через NIC1, а к серверу3 -- через NIC2
- сервер2 -- подключается к серверу 1 через свой NIC1, к серверу3 -- через свой NIC2
- сервер3 -- подключается к серверу 1 через свой NIC1, к серверу2 -- через NIC2

Меньше будет оверхеда на вычисление hash-ей в балансировке.

> Через рдп у него будет доступ только к одному серверу, права ограничены, особо не развернешься.

А сервер, значит, к сети доступа не имеет? :-)

Когда известны логины-пароли -- нужно делить полномочия на несколько учётных записей. Управление сетевым оборудованием -- одна учётка, доменом -- вторая, железом и самими серверами (имеется в виду ОС) -- третья. Для каждой системы, короче -- отдельная учётная запись с отдельным паролем.

И настроить мониторинг использования этих записей. Каждому своей. Типа, залогинился на сервак -- чик, СМС-ка пришла, типа "с вашей учёткой залогинились на сервер такой-то". Если это не ты -- то стопудово палево :-)

При одинаковой и пересекающейся адресации никакое взаимодействие двух разных подсетей невозможно. Просто по логике работы стека TCP/IP. Перед отправкой пакетов каждая машина проверяет, не принадлежит ли адрес назначения её сети. И если да -- она будет отправлять её в свою сеть.

Если нужен доступ из одного сегмента в другой, и сети именно локальные -- делайте общую политику адресации, и исключайте конфликты IP-шников. После этого всех в один VLAN, и погнали.

Если же сети удалённые, то в одной из них нужно менять IP-адресацию. Если важно сохранить подсеть 192.168.1.0 -- делите её на две части, загоняя машины из одного сегмента в адреса 192.168.1.1-192.168.1.127, а второго -- в 192.168.1.129-192.168.1.254, и ставьте везде маску 255.255.255.128. Тогда можно будет настроить машрутизацию.

У вас там в сети, чисто случайно, никто не развернул фальшивый прокси, и не раздаёт виндам его параметры через WPAD? :-)

Коммутатор рассчитан не на "устройства", коммутатор рассчитан на определённую пропускную способность и PPS (packets per second). Учитывая, что ваш коммутатор неуправляемый -- это какое-то бытовое устройство, и ожидать от него свершений по части переброски трафика не стоит.

Это первое. А во-вторых -- в винде есть мониторинг загрузки сетевых интерфейсов. Посмотрите, сколько там трафика на внешнем интерфейсе сервера. Не исключено, что вы упираетесь в интернет-канал.

Проверенный метод диагностики, безусловно, есть -- это съём основных параметров с коммутаторов и роутеров по SNMP. Для бытовых устройств, как вы понимаете, этот метод недоступен.

На вашем роутере этого не сделать. Надо или ставить перед роутером сервер с NAT, или менять роутер на нечто такое, что может показать список соединений.