smbsmb Опубликовано 1 июля, 2011 (изменено) · Жалоба Прошу помочь прикинуть смету расходов, а для этого составить предварительный проект сети для среднего предприятия. Я думаю, это решение может быть достаточно типовым, ничего сверхсложного я не хочу. Прошу покритиковать, возможно я ошибаюсь в чем-то. Деятельность нашей фирмы сильно завязана на контакты с клиентами через IP-телефонию и E-mail, поэтому стоимость продолжительных простоев мы посчитали достаточно высокой, чтобы планировать дублирующие и избыточные решения. Планируется около 35 рабочих мест с компьютерами и программными или аппаратными IP-телефонами, 3 сервера под Windows (можно виртуальных) для автоматизации предприятия, 2 безлимитных канала через разных провайдеров. 1. Резервирование сети Например, можно предусмотреть два коммутатора с 24xFE и 2 или 4 xGE, соединенные 2 кабелями или специальным кабелем в стек, чтобы при помирании одного из них другой работал. Двумя кабелями соединяем коммутаторы - чтобы работало в случае отказа порта. После такого сбоя половина компьютеров будет работать в сети, а половина нет - соответственно, в таких случаях можно либо оперативно(?) покупать и настраивать такой же коммутатор, либо предусматривать запас портов, достаточный для ручного переключения компьютеров в рабочий коммутатор. Что лучше предусмотреть? 2. Резервирование серверов Т.к. на покупку фич типа Fault Tolerance в VMWare средств все-таки нет, до планируется реализация HA с помощью бесплатного ПО типа Proxmox VE или аналогичного. Отдельной СХД не предусматриваем, т.к. если предусматривать - ее тоже надо резервировать, а это может выйти необоснованно дорого. Впрочем, расчетов еще не вел. Если при этом каждый сервер подключен через 2 сетевые карты в разные свичи, опять-таки серверы продолжат работу в случае сбоя одной сетевой карты, порта в свиче или целого свича. Но будет ли работать LACP если порты агрегированного канала в разных свичах стека? Можете привести пару недорогих примеров моделей свичей, у все это действительно может работать? Т.к. практического опыта по виртуализации маловато, уже есть пара подопытных серверов и время на эксперименты. 3. Резервирование Интернет-каналов и балансировка трафика. Допустим, каналы самые обычные - 1 внешний IPv4-адрес и NAT. Понятно, что в момент отпадания канала, через который идет трафик, буду рваться VoIP-звонки, но ничего не поделаешь - BGP и автономная система слишком дорого для среднего предприятия. Какое более-менее готовое решение можно добавить в эту схему, чтобы была возможность еще указывать вручную или автоматически, через который канал пойдет голосовой трафик? Как я помню, голосовой трафик очень чуствителен к потерям пакетов и возможно еще каким-то характеристикам канала, но сможет ли маршрутизатор автоматически отключать канала при превышении заданного порога потерь? Какие маршрутизаторы можно запланировать, чтобы они также были резервированные, возможно еще и с балансированием нагрузки каналов? Существуют ли аппаратные маршрутизаторы с Web-интерфейсом, чтобы реализовывали все это? Изменено 1 июля, 2011 пользователем smbsmb Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 2 июля, 2011 (изменено) · Жалоба Если при этом каждый сервер подключен через 2 сетевые карты в разные свичи, опять-таки серверы продолжат работу в случае сбоя одной сетевой карты, порта в свиче или целого свича. 2 сервера, 2 сетевухи на мир + 1 сетевуха с прямым линком между серверами - дабы исключить split-brain при ребуте свича те же длинки DGS3100 к примеру при появлении нового устройства в стеке ребутятся). + видел рекомендацию поднять на сетевухе(сетевухах), что смотрят на мир, вланы - и по 1-му влану гнать траф на мир, а влан 2 пользовать в бондинге с линком меджду серверами - дабы опять же обрыв одного из линков не привел к split-brain. Ну и о stonith позаботиться на всякий. Но будет ли работать LACP если порты агрегированного канала в разных свичах стека? Балансировка нагрузки - навряд. Резервирование - будет. сможет ли маршрутизатор автоматически отключать канала при превышении заданного порога потерь? Штатно - нет. Если городить костыли, с пингованием и т.п. - возможно. Какие маршрутизаторы можно запланировать, чтобы они также были резервированные, возможно еще и с балансированием нагрузки каналов? Linux-тазики, с ipvsadm. Существуют ли аппаратные маршрутизаторы с Web-интерфейсом, чтобы реализовывали все это? Сомневаюсь. Изменено 2 июля, 2011 пользователем NiTr0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
idv Опубликовано 2 июля, 2011 · Жалоба Хотелки несоизмеримы с выделяемыми средствами. Если у вас денег на AS нет - откуда они на софт и оборудование? Это раз. Ну и если честно - квалификация маловата для таких проектов... Это два. И вообще создается впечатление, что организация отказоустойчивого решения затеяна ради процесса организации отказоустойчивого решения... Это три... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 3 июля, 2011 · Жалоба Планируется около 35 рабочих мест с компьютерами и программными или аппаратными IP-телефонами, 3 сервера под Windows (можно виртуальных) для автоматизации предприятия, 2 безлимитных канала через разных провайдеров. 1. Резервирование сети Например, можно предусмотреть два коммутатора с 24xFE и 2 или 4 xGE, соединенные 2 кабелями или специальным кабелем в стек, чтобы при помирании одного из них другой работал. Двумя кабелями соединяем коммутаторы - чтобы работало в случае отказа порта. После такого сбоя половина компьютеров будет работать в сети, а половина нет - соответственно, в таких случаях можно либо оперативно(?) покупать и настраивать такой же коммутатор, либо предусматривать запас портов, достаточный для ручного переключения компьютеров в рабочий коммутатор. Что лучше предусмотреть? 1 коммутатор на 48 портов купить и забыть (типа D-link DGS-1210-48). В качестве временной замены кучка мыльниц с помойки в гирлянду - никто разницы не заметит. 2. Сетевухи в серверах (даже на десктопах) дохнут оч и оч редко (иск молния пришедшая по кабелю от провайдера) - проще держать пару сетевушек запасом. Если речь о винде, то там есть какойто лоадбалансинг между сетевухами, может и поможет. 3. Настройка метрик маршрутов и выдергивание кабеля из сетевухи - это ручной способ переключения даже в винде. С автоматом всё сложнее: нужно что то на линуксе/фряхе городить. Бесперебойник не забудьте и грозащиту на входях от провайдеров. Касательно серверов с виндой - Hiper-V юзайте, по лицензии хост машина виртуалки (если там только виртуалка используется) и виртуалка в ней - одна лицензия. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voenmag Опубликовано 3 июля, 2011 · Жалоба Сомневаюсь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 3 июля, 2011 · Жалоба Резервирование доступа в интернет - купите "аппаратный" soho-роутер с 2умя wan или сделайте костыль на linux(сложнее, но более гибко) + 1 такой же в ЗИП. Тут главное не нарваться на частый флаппинг Резервирование доступа в сеть рабочих станций и серверов - L2+-свитчи дохнут крайне редко(при нормальном питании), поэтому просто держите один свитч в ЗИПе. На рабочей станции скорее сдохнет винт(или вы планируете рейд везде делать), чем коммутатор, к которому он подключен. Самое сложное это резервирование сервисов. Тут надо смотреть на конкретные задачи. Какие-то задачи, связанные с БД можно решать онлайн-репликацией и полуручным переключением на резерв, windows-домен сам по себе имеет понятие backup contoller, вообщем тут по ситуации надо смотреть, много чего можно резервировать на уровне самого софта, а не более общими средствами типа VMWare FT, которому кроме покупки лицензий ещё и необходимо покупать общее хранилищие, желательно с подключением по SAN, а это уже совсем другие деньги. Мало того, vmware FT это не просто так взял и понажимал next, next, next, тут надо знать что такое раздвоение головы и что надо делать, чтоб его не случилось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...