athacker

Полную формулировку задачи приведите.

Трафик-то от клиентов прилетает на эту машину? :-)

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

У нас заббикс интегрирован с системой обработки инцидентов. В заббиксе заводятся различные actions, которые проверяют группу хоста с проблемой, и заводят инцидент соответствующего приоритета.

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, на линуксе ключи могут отличаться.

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

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

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

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

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

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

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

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

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

Поддержу камрада AntHTML

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

У нас на заббиксе мониторится инфраструктура:

Number of hosts (enabled/disabled/templates) 5765 5512 / 111 / 142
Number of items (enabled/disabled/not supported) 538807 523119 / 12809 / 94
Number of triggers (enabled/disabled [problem/ok]) 130488 128402 / 2086 [17 / 128385]

Шаблоны, графики, SNMP, IPMI, трапы -- всё это оно умеет.

NAS4FREE по дефолту всё на ZFS делает. У ZFS есть квоты на датасет.

Если по-простому, то можно сделать так: отключить все порты коммутаторов, которые не используются. На коммутаторе настроить port security -- чтобы каждый порт был с привязкой по MAC. Если будет воткнутно устройство с другим MAC-ом, то сеть у него не поднимется. Соответственно, для того, чтобы воткнуть ноут или что-либо другое -- придётся сначала из включенного порта выткнуть то, что туда уже было подключено, и настроить на "нелегальной" железке такой же MAC, как и на легальной.

Либо таки да -- 802.1x. Но для этого нужно и соответствующее оборудование, и поддержка со стороны клиентов (рабочих станций, или чо там ещё у вас в сети).

А на FreeBSD эта задача никак не решается. Можно контролировать доступ в интернет, допустим, через прокси с авторизацией. Но не подключение/отключение устройств в сети, этим в любом случае коммутаторы заведуют. Ну, хотя если решитесь на 802.1x, тогда на фре можно RADIUS-сервер поднять :-)

Самба на фре всегда страдала проблемами с производительностью. Насколько мне известно, это не лечится никак. Были у сообщества одно время попытки аппелировать к команде Самбы на эту тему, но они закончились после ответа от Samba team в духе: "Идите лесом, у нас на линухе всё работает ровно". Так что если от Самбы реально нужен гигабит -- ставьте её на линух.

man xbmc

Линукс зло, FreeBSD надо ставить.

У нас хранилки на чистой фре работают. 2x10Gbit сетевухи, multipath, тонкое провизионирование, VAAI, все дела. На дисках ZFS в разных позах (zmirror, raidz{2}). Луны создаём на zvol'ах, iSCSI target -- на базе ctld. Всё работает чотко.

1. В целом, равнозначны. Но зависит от того, что вы хотите получить на выходе :-)

2. А вы проверяли у таких пользователей, IP-адрес, который у них на интерфейсе -- он снаружи виден? :-) Или на интерфейсе один белый IP, а если зайти на какой-нибудь 2ip.ru, то там будет совсем другой адрес?

Технически это может быть реализовано так -- у провайдера есть несколько BRAS'ов, к которым подключаются по PPPeE пользователи. В рамках одного BRAS'a адреса должны быть уникальны, а в рамках всего набора BRAS'ов могут и совпадать. У нас так делается, например. Только не с белыми IP, разумеется, а с серыми. Зачем клиентам в этой схеме белые IP выдавать, я не знаю. Каждый BRAS выдаёт IP-адреса клиентам из диапазона 10.0.0.0/16. Т.е. на 1-ом брасе может быть клиент с IP 10.0.0.1, и на втором брасе может быть клиент с таким же IP-шником. Но вот одновременно два клиента на 1-ом BRAS'e не могут получить IP 10.0.0.1, понятное дело. Иначе маршрутизация сломается.