athacker

1) Направленная антенна с усилителем и поиск операторов/вышек в округе с более быстрым интернетом.

2) Если 1 не помогает -- то односторонний спутник. Запросный канал по мобильной сети, ответ -- через спутник. Вешаем любую оффсетную антенну диаметром от 1.2 метра (хотя ХЗ, смотря какой провайдер/спутник/географическое положение, может, И на 0.6 м можно сносно ловить будет), в комп ставим DVB-карту (цена от 3000 руб), настраиваем и вуаля. Скорость, конечно, будет зависеть от запросной (наземной) сети, но всяко будет выше, чем 1 кб/сек.

Есть также компрессоры/ускорители трафика, как раз для односторонних спутников. Например, globax.biz

Кстати, вашего DSL-провайдера тоже можно использовать как запросный канал, трафик там при запросе небольшой. Только если что-то в интернет заливать будете -- тогда да, расход исходящего трафика будет выше. Но с другой стороны, провайдер исходящий трафик может как раз и не тарифицировать, надо условия подключения смотреть :-)

В винде штатным chkdsk'ом можно поверхность поскрести.

На линуксах -- накатите файловую систему ZFS, у неё встроенный scrub, она проверяет сама диски регулярно.

Да, в сервера можно. С неродными дисками, как правило, проблемы только в брэндовых СХД.

По факту вам надо один сервер и один роутер. Сервер файловый, и роутер на раздачу интернета. В качестве сервера настоятельно рекомендую что-нибудь вроде tinyurl.com/j665ara
Это хорошая железка, с удалённым управлением и всем таким, с корзиной на 4 диска и возможностью подцепить ещё один внутри (для установки системы, например). В качестве системы можно поставить FreeNAS, например.

Роутер -- можно какой-нибудь микротик, даже бытовой RB750. Ну или если очень хочется повозиться -- любой комп с двумя сетевушками и установленной на борт FreeBSD/Linux.

Не нужно его использовать. Его и раньше не надо было юзать, а уж в свете новостей об утечке кучи учётных записей teamviewer налево... arstechnica.com/security/2016/06/teamviewer-says-t...

1. www.howtogeek.com/howto/8739/restrict-users-to-run...

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

3. Создайте для продавца учётную запись пользователя, без админских прав.

SAN -- это несколько сложнее, чем просто пачка серверов с дисками, включенные в сеть :-)

> Я бы хотел собрать кластер iscsi(не знаю правильных названий), чтобы подключаться к
> нему и хранить на нем виртуалки для миграции между серверами(имеется ввиду
> виртуализация на самом сервере который играет роль хранилища)

Вы смешали в кучу целую кучу понятий, простите за каламбур :-) iSCSI -- это, если на пальцах, сетевая версия протокола SCSI, который предназначен для доступа к блочным устройствам (хранилищам) через сеть.

Миграция -- оно совсем никакого отношения к iSCSI не имеет, и реализуется целой кучей технологий, далеко не только с помощью iSCSI-хранилищ.

"виртуализация на самом сервере, который играет роль хранилища" -- это то, что по-модному называется "конвергентная система". И реализуется отдельной пачкой технологий и продуктов, совсем не обязательно включающих в себя iSCSI.

В общем, в зависимости от того, что конкретно вы по итогу хотите получить, сценарии и используемый софт будут разными. Блочное хранилище, миграция и конвергенция -- вещи, конечно, связанные, но не одно и то же. Примерно как Карл Маркс и Фридрих Энгельс или, если угодно, Ленин и партия ;-)

Отвечу по последнему пункту, по конвергентной системе. Если есть желание добиться именно этого, то совсем бесплатно и с большим геморроем можно посмотреть в сторону ceph. На сервера можно поставить линукс, на линукс какой-нибудь гипервизор (типа KVM), а также компоненты ceph. И устроить из всего этого конвергентную систему.

Есть вариант реализовывать хранилище на виртуальных машинах. Т.е. в первую очередь ставится гипервизор, на нём разворачивается некоторое количество виртуальных машин, в которые презентуются диски с серверов, а потом на основе этих виртуалок сшивается общее хранилище. Так делает EMC ScaleIO, например. По сравнению с Ceph, ScaleIO гораздо проще и логичнее устроено, имеет компоненты и драйвера доступа для линукс, винды и драйвера напрямую под ESXi (т.е. не надо морочиться с сетевыми протоколами типа iSCSI или NFS). Но есть и недостатки -- оно бесплатно официально только для тестовых окружений. Соответственно, в продакшене можно юзать только на свой страх и риск, поддержки от производителя не будет. И оно не очень хорошо документированно по части своих внутренностей. Есть мануалы "как развернуть" и "как управлять", а вот мануалов "как оно может сломаться, почему, и как это чинить" -- увы, нет. Тут только либо натурными экспериментами, либо с помощью сообщества (оно небольшое, но есть), либо забить и использовать что-нибудь другое :-)

tcpdump что показывает?

Если решать костылями -- сбрасывай в лог каждые 5 минут по крону результат команды "ps -xau | sort -nk5 -r", с фиксацией времени, когда команда запущена. Оно тебе в лог будет писать список процессов, отсортированных по полю VSZ (virtual size) в обратном порядке (самые большие -- в начале списка). Вот и ищи, кто там шалит.

NB: Синтаксис команды приведён для FreeBSD, на линуксе ключи могут отличаться.

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

Начните с больших кусков:
==== Для 2000 устройств ==========
Network: 192.168.48.0/21
HostMin: 192.168.48.1
HostMax: 192.168.55.254
Hosts/Net: 2046
==== Для 600 устройств ==========
Network: 192.168.56.0/22
HostMin: 192.168.56.1
HostMax: 192.168.59.254
Hosts/Net: 1022
==============
И у вас ещё остаются 4 свободные сети по /24:
192.168.60.0/24
192.168.61.0/24
192.168.62.0/24
192.168.63.0/24

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

Придумайте себе сеть организации. С доменами Active Directory, с внутренней почтой (сначала, допустим, на linux/FreeBSD/postfix/dovecot, а потом -- на Exchange, или наоборот), с внутренними DNS и DHCP-серверами.

С файловыми серверами, доступ к которым на уровне доменных учётных записей и групп распределяется. И запилите эту сеть на виртуальных машинах. Несколько виртуальных серверов Windows/Unix, парочку клиентских станций с виндой/линуксом.

Поднимите свой веб-сервер, нарисуйте на нём простенький веб-сайт на базе какой-нибудь популярной CMS типа Joomla, Wordpress, чо-там-ещё-нынче-модно.

Потом придумайте этой конторе удалённый филиал, и постройте инфраструктуру для него, и чтобы между ними ещё и VPN был, и с маршрутизацией правильной, чтобы машины из одного филиала видели другой, и наоборот.

А потом сделайте так, чтобы VPN-канал между филиалами был зарезервирован через двух разных провайдеров, да причём переключения производились автоматически и абсолютно прозрачно для клиентов. В этом вам поможет динамическая маршрутизация и протоколы OSPF или BGP.

Факультативно -- можете поднять в удалённом филиале так называемый RoDC -- read-only domain controller :-)

Вот когда всё это запилите, то приходите за новым заданием.

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

Очень любят почему-то спрашивать про роли FSMO :-) Их состав, назначение и что будет, если какая-то из них сломается.

Почтовый сервер поднять не так уж сложно, как тут ряд ораторов утверждает. В целом же -- если вас не парит, что конторскую почту может читать "потенциальный противник", то можно пользоваться публичными сервисами -- гуглом, яндексом, чем угодно. Лично я предпочитаю, чтобы почта ходила через свой сервер.

1) Пробросить порт достаточно.

2) Домен нужно регистрировать в любом случае, свой у вас DNS-сервер или не свой. Как-то же снаружи к вам почта должна приходить? А для этого нужно, чтобы доменное имя и MX-записи были публично доступны.

3) Обратную зону прописывать обязательно, иначе будут постоянные проблемы с тем, что от вас почта не будет приниматься адресатами в других доменах. SPF -- тоже должна быть обязательно. Обратную зону нужно просить прописать вашего провайдера, а SPF нужно прописывать на том публично доступном DNS-сервере, куда вы делегируете своё доменное имя.
4) MX и A должны быть прописаны там же, где и SPF :-) Вы регистрируете домен и делегируете его на какой-то DNS-сервер. Можете поднять свой, можно воспользоваться DNS-серверами регистратора (как правило, регистраторы доменных имён предоставляют такую возможность, и некоторые даже бесплатно, если регистрируете домен у них).

Микротик RB-951 подойдёт? :-) Я там генерил кастомный сертификат для веб-интерфейса управления.

Центральные контроллеры AD -- на центральной площадке.

В филиалах -- ставим и настраиваем RODC.

Про избыточность отдельного Exchange для каждого филиала -- согласен с предыдущим оратором.

А почему "в филиалах разные подсети" -- через "но"? :-) Оно именно так и должно быть -- у каждой площадки должна быть своя IP-подсеть. А то и не одна, если площадка большая.

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

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

- брать минимум два сервера для резервирования
- предусматривать отказоустойчивое дисковое хранилище (дисковое хранилище -- потому что серверов у вас два, и обоим нужен будет доступ к общей хранилке. То есть -- это либо СХД, либо распределённая файловая система (но тогда серверов нужно вам больше, чем 2).

Поэтому с арендой физического железа возни будет гораздо больше, чем купить маленькое облачко у сервис-провайдера. Ну, самые известные примеры -- это Amazon, Azure, DigitalOcean. Из отечественных навскидку -- КРОК, ДатаЛайн, СофтЛайн, Селектел, Наука-Связь.

Учебные центры-то есть, но стоимость этого обучения...

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

СХД, как и многие другие вещи -- это дело такое... Если у вас возникает вопрос "а зачем нужны СХД", то значит, вам она точно не нужна :-)

В чём профит СХД -- это многократно зарезервированная система. У неё от двух до N контроллеров, каждая дисковая полка подключена минимум двумя путями, каждый диск подключен двумя путями (SAS-диск, конечно же), и на дисках используются механизмы типа T10-PI, гарантирующие целостность данных. Диски имеют пропатченные прошивки, логика работы этой прошивки такова: "лучше мы ложно зафейлим диск, чем случится реальный сбой, а мы его прошлёпаем и потеряем данные".

Также есть всякие функциональные штуки типа моментальных снапшотов, механизмов репликации (когда у вас два географически разнесённых тома имеют полностью одинаковое содержимое и синхронизируется практически в прямом эфире). СХД умеет tiered storage, когда система реализует кэш наиболее горячих данных на базе SSD-дисков или в RAM.

Но надо понимать, что сама СХД и расходники для неё будут стоить как крыло от F-35, и СХД нужно брать ТОЛЬКО с соответствующими сервисными контрактами. Без сервисного контракта -- любой сбой будет вам обходиться в копеечку, а время ремонта может исчисляться месяцами. С другой стороны, СХД довольно надёжны, и количество сбоев у них не очень велико. С третьей стороны, вендоры очень любят брать деньги за воздух. Например, у IBM есть такая практика -- если у вас истёк сервисный контракт, а вы его не продлили, а потом у вас случился сбой и вы решили купить сервисный контракт обратно, то вам в стоимость добавят стоимость годичного сервисного контракта в виде штрафа. Т. е. если вы решите спустя N лет приобрести сервисный контракт на 2 года, то по факту заплатите как за 3 года -- "1 год условно" вам выставят в виде штрафа. Этим грешит не только IBM, но и ещё ряд вендоров.

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

Для чисто файловых хранилищ подойдёт, например, Windows Storage Spaces в конфигурации с двумя серверами и одной двух-контроллерной корзинкой DAS, подключенной к обоим серверам. Это гораздо дешевле СХД, а многие вещи такая конфигурация умеет -- нет единой точки отказа, умеет RAID на дисках, умеет условно tiered storage и умеет снапшоты средствами VSS на винде.

На фре тоже сейчас активно пилят High Availability в ctld. Полагаю, включат в 11.0, и можно будет строить отказоустойчивые iSCSI-хранилки на основе FreeBSD+ZVOL+ctld -- отличный вариант под хранение виртуалок. Причём ZFS тоже умеет снапшоты, вот если бы Veeam научился с ними работать, была б ваще чума... :-)

В топике набег линуксоидов :-) ХЗ, те, кто жалуется на какие-то проблемы на фре -- просто не умеют её готовить. Банально, да? :-) На трёх моих последних местах работы фря использовалась по полной. И на текущем месте работы выносим с линукса всё, что можно, и оставляем только то, что нельзя -- как правило, сильно специфичный софт, разработанный только под линукс. Всё остальное -- PPPoE-сервера, веб, почта, мониторинг, вспомогательные сервера, файловые сервера -- всё крутится на фре. Никаких проблем, что характерно, при этом мы не испытываем.

Я не знаю, какие там технологии используют ораторы выше, которые они не могут использовать на фре, но никаких принципиальных ограничений именно FreeBSD как платформы, я не встречал.

Есть проблемы конкретных продуктов на фре -- это да. Про битрикс не скажу, но производительность самбы на линуксе выше, чем на фре. Но это проблема не системы, а скорее самой самбы, разработчики которой не захотели разбираться с проблемами самбы на фре.

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

Любые "универсальные" сервисы на фре работают нормально. Про проблемы с пакетными менеджерами -- это трэш, линуксоиды всё врут :-) Они сильно отстали от жизни, особых проблем с пакетными менеджерами давно уже нет. Отдельно доставили сказки про то, что если ты собираешь софт из портов, то потом с пакетами у тебя будут проблемы :-)

ZFS на линуксе сильно отстаёт по функционалу от ZFS на фре. В ZFS-on-linux только в прошлом релизе был добавлен алгоритм сжатия lz4, что на фре есть уже больше двух лет. Недавно была добавлена поддержка ACL, что опять-таки, фря умеет уже давно.

Короче, примеров можно привести миллион, но вывод довольно простой -- не надо верить заявлениям, что "инструмент XXX -- это фу-фу-фу, а инструмент YYY -- это ого-го". У любого из них есть свои плюсы и минусы, просто нужно их знать, и использовать подходящий инструмент. Если вы планируете настраивать сервера "в корпорации" или для задач провайдера связи, или просто свой сайтик в интернет выложить -- и фря, и линукс эти задачи решит отлично. Если будете делать какую-то хранилку, под виртуализацию, например -- я бы использовал фрю. Если же у вас план делать крупный высоконагруженный web-проект -- возможно, тут линукс подойдёт лучше.

Я, как бывший корпоративный админ, а ныне админ интернет- и сервис-провайдера, никаких проблем с фрёй в своей работе не испытываю.