Как начать разработку агента — межсетевого экрана?

kinton, ничего, что проект WIPFW уже 8 лет как не развивается? :-)

Как защитить коммутатор от L2 петли без отключения избыточного линка?

Сослан Хлоев, коммутатор среагирует на петлю (и отрубит один линк), если увидит STP BPDU со своим идентификатором. А их будет транслировать только другой коммутатор. А т. к. тут один коммутатор и остальные сервера -- то ничего не будет. А конкретное поведение будет определяться тем, с какого MAC-адреса анализатор будет отправлять обработанный трафик. Если с того же, на который он принимает не обработанный, то коммутатор просто в следующий раз отправит пакет от платформы в порт 1 коммутатора. А на порту 2 трафика не будет вообще.

Как защитить коммутатор от L2 петли без отключения избыточного линка?

Насчёт L3 -- зависит от общей схемы. Откуда вы берёте трафик, что это за сети, как они попадают на вашу платформу и т. п. В общем случае, для платформы нужно указать, что такие-то DST сети у нас за IP, висящем на анализаторе. Анализатор трафик получил и отправил через другой интерфейс, на другой IP платформы. На платформе должны быть две таблицы маршрутизации -- для входящего трафика от клиентов и последующей отправки на анализатор, и для входящего (уже проанализированного трафика) от анализатора, который будет отправляться дальше по маршруту (в интернет, например).

Как защитить коммутатор от L2 петли без отключения избыточного линка?

А у вас на интерфейсах 1 и 2 анализатора одинаковые маки, что ли? Если да, то ваша схема вообще работать не будет, независимо от изоляции портов. Т. к. в момент отправки анализатором первого же пакета проанализированного трафика коммутатор будет править TCAM, и записывать, что такой-то MAC у него висит за портом 1. А значит, следующий пакет, который платформа попытается на этот мак завернуть, уйдёт через порт 1 коммутатора и попадёт на порт 1 вашего анализатора.

А если маки разные (т. е. "внешняя платформа" подменяет DST MAC на один MAC, а анализатор, когда отправляет пакет после анализа, отправляет пакет с другого SRC MAC, не совпадающего с тем, который подставляет платформа), то проблемы как бы вообще нет -- коммутатор видит два порта, к которым подключены устройства с отличающимися маками.

Кстати, а какой смысл блокировать ЧАСТЬ пакетов в TCP сессии? :-) Это равнозначно обрыву соединения. Клиент не увидит части пакетов, и отправит серверу сообщение о том, что пакеты такие-то не дошли. Сервер повторит отправку. Ваша система опять их заблокирует. Клиент опять пожалуется. И так будет повторяться, пока соединение по глобальному таймеру не сбросится. Тогда уж можно сразу подделывать TCP RST от сервера, чтобы клиент сразу соединение сбросил.

Возможна ли переконфигурация raid1 в raid10, gmirror - freebsd без потери данных?

Saboteur, это я не в курсе, давно не работаю с аппаратными серверными рейдами :-) Надо даташиты читать.

Возможна ли переконфигурация raid1 в raid10, gmirror - freebsd без потери данных?

man oce (online capacity expansion)
Практически любой современный RAID-контроллер умеет это делать. Другое дело, что у разных вендоров реализован разный набор преобразований. Ну, скажем, некоторые умеют RAID1 в RAID5/6 переделать, а некоторые -- нет.

Как лучше организовать IT-инфраструктуру предприятия?

KTG, если вы строите гостевой кластер (т. е. кластер средствами приложений ВНУТРИ виртуальных машин), то виртуалки, входящие в кластер, должны работать на разных физических хостах. Потому что если они на одном, и физический сервер ляжет -- у вас ляжет и все ваши виртуалки, образующие кластер.

Как лучше организовать IT-инфраструктуру предприятия?

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

Я правильно понимаю, Россию собираются вообще изолировать от "мирового интернета"?

Алексей Николаев, это то же самое. Не надо идеализировать Германию, у них полно своих внутренних проблем. Просто они со стороны не так заметны. И с интернетом, кстати, у них там хуже, чем в России. Ниже доступность, ниже качество, выше цены. Вдобавок, Германия до сих пор -- оккупированная страна, они просто не в состоянии принимать бОльшую часть решений самостоятельно.

Я правильно понимаю, Россию собираются вообще изолировать от "мирового интернета"?

Алексей Николаев, верно, мы не в Германии. Для информаци -- в Германии пенсионный возраст 67 лет. Для всех :-)

Стоит ли изучать freebsd?

CityCat4,

если я не последую HCL - меня пошлют в саппорте

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

Стоит ли изучать freebsd?

CityCat4,

Semy, в нормальное конторе на человека, который хочет поставить на сервер FreeBSD посмотрят как на неведомое нечто.

Я внедрял фряху в одной конторе, в которой работал. Раньше там использовали только и исключительно линуксы. В частности, для задач организации стораджей для виртуализации. Я перевёл парочку на фряху, и они до сих пор в этих задачах используют фряху, заметно расширив парк серверов. И это несмотря на то, что я быстро оттуда ушёл, и был единственным BSD-шником. Т. е. полученный профит оказался достаточным, чтобы прокачать сотрудников в BSD и не отказываться от её использования для задач организации хранилищ.

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

Стоит ли изучать freebsd?

CityCat4, мой коллега стыковал астериск под фряхой с офисными панасониками (АТС). Всё норм работало.

Какая разница в производительности windows под vmware esxi и чистой windows?

Потери производительности в любом случае будут, но если у вас это единственная виртуалка, то вряд ли эти потери будут заметны.

Как лучше организовать IT-инфраструктуру предприятия?

Товарищ, два ФИЗИЧЕСКИХ хоста с гипервизорами вы никогда по этому сценарию не кластеризуете. Просто нет таких технологий. Точнее, есть, у одного вендора -- VMware. Называется "fault tolerance". Но у неё столько ограничений, что фактически её использовать можно только от безысходности (например, для организации отказоустойчивости легаси-приложений, которые в принципе не умеют кластеризоваться).

Синхронизация гостевого кластера-- средствами самих приложений, которые работают внутри виртуалок, разумеется. Всё зависит от самих приложений, и механизмов, которые они (приложения) используют для кластеризации.

DNS и контроллеры доменов -- не кластеризуются. У клиентов просто есть механизм failover'a, и если один сервер не отвечает, клиент просто спросит другой. Вот базы данных -- тут да, нужна будет кластеризация. Параметров, влияющих на выбор решения -- миллион. Что за база, какие поддерживает механизмы кластеризации, автоматизирован ли failover/failback, какая на неё нагрузка, какие требования к RTO/RPO. Возможно, что кластеризация баз вообще не нужна будет, и достаточно будет одной виртуалки, а в случае проблем её просто восстанавливать из бэкапа.

В качестве гипервизора -- посмотрите лучше в сторону KVM/libvirt или Proxmox. Или бесплатный Windows Hyper-V Server. XenServer не популярен, и поэтому сообщество у него невелико. И проблемы в эксплуатации придётся решать самостоятельно, а для этого нужна квалификация ого-го.

Как лучше организовать IT-инфраструктуру предприятия?

KTG, хранилка стоит дороже серверов. Пустая HPE MSA 1050 (без дисков) -- уже по GPL тянет на 400 тысяч.

Сервера можно искать БУ, на авито. Там можно купить приличное ещё железо тысяч за 50-60. Но для хранилок это не зайдёт. Эксплатировать хранилку без поддержки -- это очень сильно рисковать.

Так что остаётся самосбор на базе пары серверов и технологий SDS типа MS SoFS или связки FreeBSD+ZFS+ctld+CTL_HA. Или линукс с DRBD в каком-то виде. В общем, не обладая опытом в этой сфере, ресерчить придётся не одну неделю.

Как вариант -- делать конвергентную систему. Т. к. хранилок нет вообще, просто 4-5 серверов. Посмотрите Nutanix community edition, возможно, вам хватит её функционала и лимитов. Но у них в требованиях SSD и сеть 10G.

Как лучше организовать IT-инфраструктуру предприятия?

Да, по поводу охлаждения. Во-первых, нет никаких "стоечных систем охлаждения". Охлаждаются не стойки встроенным оборудованием, а помещение серверной целиком, с помощью кондиционеров. Принято считать, что мощность системы охлаждения должна быть такой же, как суммарная максимальная мощность установленного оборудования. В идеале же, суммарная мощность системы кондиционирования должна совпадать с мощностью ИБП. Кондеев должно быть не менее двух, и каждый должен иметь возможность сохранить температуру в помещении серверной не выше 23-24 градусов при любых условиях снаружи (т. е. даже если на улице +40). Либо продумайте возможность дополнительного мобильного (напольного) кондиционера, который можно подоткнуть в случае отказа 1-го кондиционера в серверной и недостаточной мощности оставшегося.

Как лучше организовать IT-инфраструктуру предприятия?

KTG, если вы говорите про кластер виртуализации, то нужно как минимум 2 сервера для этого кластера (причём каждый должен быть загружен не более чем 50%, по очевидным причинам) и отдельное отказоустойчивое дисковое хранилище (такое как промышленная СХД). Либо тоже кластер, но из двух серверов хранения. Бюджеты будут соответствующие, СХД -- довольно дорогие железки. Сделать два гипервизора и хранить виртуальные машины на их локальных дисках -- это не про отказоусточивость. Сервер ляжет, и машины лягут вместе с ним, т. к. лежали на его же дисках.

Да, и отвал физического сервера, даже если у вас общий дисковый storage и полная high availability настроена, пользователи всё равно заметят, т. к. машины с упавшего сервере ПЕРЕПОДНИМАЮТСЯ на оставшихся в живых хостах. Т. е. с точки зрения наружного наблюдателя это выглядит как нажатие кнопки reset на соответствующей виртуалке.

Если же речь про гостевую кластеризацию, то... Тут тоже масса нюансов. Смотря что за кластеризация. В случае с Postgres, например, перенос сервиса полностью автоматическим считать нельзя. Есть решения, но они с теми или иными ограничениями. Поэтому в общем случае можно считать, что сделать полностью автоматический перенос сервиса БД на Poesgre нельзя. Можно сделать автоматизированный, но принимать решение и выполнять переключение придётся всё равно админу.

Как лучше организовать IT-инфраструктуру предприятия?

Нет никакого феншуя!
Есть требования диктуемые бизнесом.

Ну это не совсем так. Ибо требования бизнеса известны -- SLA 99.9999, RTO=0, RPO=0, стоимость реализации = 0 :-) Что, разумеется, нереализуемо. И вот тут-то возникает фэншуй... :-)

Как лучше организовать IT-инфраструктуру предприятия?

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

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

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

SMS -- самый надёжный способ доставки оперативных оповещений. Потому что для любых других способов требуется интернет. Который, как ни странно, может отпадать. Причём с двух сторон -- как со стороны вашей инфраструктуры, так и со стороны телефона, на который должно прийти оповещение. Поэтому я делаю так: основной канал отправки оповещений -- это интернет (почта, плюс дублирование по SMS через оператора рассылок, т. е. в любом случае, на телефоне не нужно постоянно поднятым интернет держать). Резервный канал оповещения, когда недоступен шлюз SMS-оператора или упал интернет -- это чистый GSM, как раз вот на этом самом UniPing. Там вставляется симка, есть антеннка, и API для отправки SMS через устройство.

По поводу корзин с дисками -- да, они все выглядят примерно одинаково :-) Железка с кучей отсеков под диски. Только вот внутренняя организация очень отличается, и что это -- СХД, DAS или NAS определяется не внешним видом, а начинкой и поддерживаемыми протоколами. Такими как SAS, FC, iSCSI, NFS, SMB и так далее. Одна железка может презентовать объёмы по разным протоколам, как блочным (FC, iSCSI), так и файловым (SMB, NFS). Это умеют делать все современные СХД.

Почему например не стоит на одной виртуалке держать dhcp и dns? Почему под контроллеры доменов 2 машины?

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

Для критических сервисов требуется резервирование. Поэтому делаются 2 и более виртуальных машин, которые работают на разных физических хостах и хранятся на разных физических дисковых накопителях. Это даёт вам отказоусточивость и возможность обслуживать сервисы без перерыва. Т.е. надо вам обновить систему на DNS-сервере -- взяли один, обновили. Пока идёт работа по обновлению, запросы пользователей идут на второй DNS-сервер, и никто ничего не замечает. Закончили работу с сервером, вернули его в строй, и можно обновлять второй. Штатная работа, "ни единого разрыва".

С контроллерами домена -- та же история. Это критичный сервис для работы всей инфраструктуры, при его отвале весь офис работать не сможет. Поэтому нужно резервировать. Бэкапы -- это прекрасно, но они не всегда помогают. Может случиться так, что вы из бэкапа поднимаете виртуалку, а бэкап битый, и она не стартует. Или слишком старый, т. к. вы не уследили и резервное копирование этой виртуалки сломалось 2 месяца назад. И так далее -- масса нюансов.

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