Содержимое: как сделать так, чтобы компьютер отвечал в интернете на все свои IP-адреса по всем своим интерфейсам, каждый из которых имеет шлюз по умолчанию. Касается и серверов, и десктопов.

Ключевые слова: policy routing, source based routing

Лирика: Есть достаточно статей про policy routing в Linux. Но они чаще всего разбирают общие, более тонкие и сложные случаи. Я же разберу тривиальный сценарий следующего вида:



Нашему компьютеру (серверу) доступно три интерфейса. На каждом интерфейсе шлюз ему выдал IP (статикой или по dhcp, не важно) и сказал «весь трафик шли мне».

Если мы оставим эту конфигурацию как есть, то будет использоваться принцип «кто последний встал, того и дефолтный шлюз». На картинке выше, если последним поднимется нижний интерфейс (241), то в него будет отправляться весь трафик. Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).

Другими словами, в обычном варианте будет работать только один интерфейс. Чтобы сделать ситуацию хуже, если адреса получены по dhcp, то обновление аренды на других интерфейсах может перезаписать шлюз по умолчанию, что означает, что тот интерфейс, который работал, работать перестанет, а начнёт работать другой интерфейс. Удачной стабильной работы вашему серверу, так сказать.

Решение

Наступает момент когда виртуального хостинга становится недостаточно и Ваш проект так и «просится» на сервер. Не всегда для новых задач Вам понадобится сразу выделенный сервер, но как минимум с виртуального сервера начать стоит. При этом многие из Вас, что бы как то сэкономить начинают искать партнера(ов) для аренды более производительной услуги. Также, одним из вариантов экономии бюджета — есть использование бесплатного программного обеспечения.

Ведь не каждому из Вас, например, будет приятно сидеть в консоли и устанавливать необходимое ПО, или производить управление Вашими сайтами через туже командную строку. В такие моменты на помощь многим вебмастерам приходят панели управления хостингом, и как же приятно когда эта панель — именно качественный и бесплатный софт. Совсем недавно мы уже рассказывали об одном бесплатном программном продукте, ну а сегодня речь пойдет об еще одной интересной панели управления хостингом, а именно о «монетке»…



Думаю многие из Вас догадались, что речь пойдет о CentOS Web Panel (CWP). В отличие от многих других панелей управления CWP позволит автоматически развернуть полный стек LAMP с кэшированием на уровне веб-сервера посредством Varnish Cache — это замечательно решение для хранения «горячего» кэшируемого контента Ваших веб-страниц в оперативной памяти. Оно позволит ускорить Ваш веб-сайт, и в то же время уменьшит нагрузку на процессор.

Puppet, Chef, Ansible — это так называемые системы управления конфигурациями, которые можно часто встретить в зарубежных IT вакансиях типа Server/DevOps Admin. Фактически же это мощные инструменты которые могут полностью настроить нулёвый сервер или же достаточно быстро массово перенастроить набор из 1-100+ серверов. Работа с пакетами, с командной строкой, файлами настроек, доступно всё.

Общий обзор можно прочитать в публикации «Как стать кукловодом».

Собственно к написанию этой начальной статьи для Puppet меня сподвигло крайне скудное описание во встречающихся в интернете результатах. И даже при использовании официальной документации умудряешься наткнуться на кучу грабель и подводных камней и получить не то, что ожидал.

Причина использования ветки 3.8, вместо 4.3 заключается в использовании именно этой версии на «моих» серверах из-за наличия именно этих пакетов в репо. Платный вариант Enterprise также не рассматривается, т. к. я с ним не работал. Причина использования Centos – он достаточно широко распространён, включая доработанные версии от Amazon.

Для локальных тестов можно использовать две виртуалки на VirtualBox под CentOS-6.5-x86_64.

Решил написать эту статью после знакомства с публикацией «HP, Dell и IBM: компоненты, отвечающие за надёжность сервера», поскольку имею другое мнение насчёт некоторых моментов. Эта статья не претендует на инновационные подходы, а просто описывает полученный опыт и, надеюсь, предотвратит банальные ошибки.

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

Освоил expect и сразу в бой. Написал, опробовал, получилось. Теперь делюсь с Вами, может кому и пригодится.

Не так давно нами была запущена услуга облачных VPS. За счет полного root-доступа к виртуальному серверу и своей небольшой стоимости она стала довольно популярной среди наших клиентов. Кто-то переезжал на облачные VPS с виртуального хостинга, так как клиентам было важно иметь именно доступ суперпользователя, а кто-то хотел использовать своим выделенный IP-адрес и не делить его с недобросовестными соседями.

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



Если говорить о большинстве наших услуг хостинга, то в стоимость практически всех из них включена лицензия панели управления ISPmanager, чего не скажешь про облачные VPS. Учитывая цену данных виртуальных серверов — это и не удивительно. Но многие наши клиенты хотели и вместе с такой бюджетной услугой иметь возможность использовать удобную панель управления хостингом, но при этом мало кто готов был оплатить лицензию разработки той же компании ISPsystem — ISPmanager, которая довольно популярна в рунете. Здесь их позицию понять можно, и после того как обращения в нашу поддержку по данному вопросу участились — мы решили составить свой обзор бесплатных панелей управления хостингом. Те, кому это интересно — милости просим под хабракат…

Недавно мы рассказывали о том, в каких проектах Центра речевых технологий (ЦРТ) используется наша ИТ-инфраструктура и делились экспертным мнением относительно взаимодействия IaaS и бизнеса.

Сегодня мы решили взглянуть на рынок в целом и дать краткий обзор трендов IaaS.

Наступает момент, когда системному администратору необходимо определить дату последнего входа в систему каждого из пользователей, а также подготовить список тех аккаунтов, которые этого так и не сделали. Если б Вы ранее не знали команду lastlog, то удивились бы, насколько легко и быстро она может предоставить Вам эти данные.

Добрый день, %username%!
Как-то мы с компанией друзей решили сделать интернет радио, но как оказалось, выделяемого места на VPS недостаточно для большого архива музыки, более того покупка дополнительных гигабайтов — настоящий грабеж.

В этом посте я расскажу про не очень известные особенности языка YAML.

Пролог

Системное администрирование за последние несколько лет несколько изменилось. Вместо маленьких скриптиков на bash у нас теперь огромные проекты системы конфигурации. Puppet с миллионом модулей готов «отконфигурять» для нас любую машинку, все поставить и все настроить. И конечно же, венчает это торжество автоматизации Hiera — система управления системой управления.

В начале идея выделения всех конфигурационных данных в иерархическую структуру и редактирования красивых и удобных YAML файлов кажется невероятно соблазнительной, особенно если вспомнить множество форматов конфиг-файлов, создатели которых, кажется, участвовали в соревнованиях по оригинальности мышления. Однако очень уже скоро мы оказываемся с тысячами строк YAML. Давайте посмотрим как можно использовать YAML чтобы наши конфигурации было легче читать и поддерживать.

Мы постоянно делимся опытом оптимизации служебных систем нашего IaaS-провайдера:

• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня наше внимание привлек кейс Ticketmaster. Попробуем кратко его проанализировать.

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

Ранее мы рассказывали о том, как мы реализовали предустановленную панель управления и дозаказ лицензий на лету. Помимо этого мы писали о работе нашего API и разработке собственного DNS-менеджера. Сегодня мы кратко проанализируем наш опыт работы разных типов дисков на одной виртуальной машине.

Постановка задачи.

Под термином “клиент” будем понимать зону ответственности за совокупность сетевых устройств.

Требуется обеспечить доступ для нескольких сотен клиентов к неким общим ресурсам в таком режиме, чтобы:

1. Каждый клиент не видел трафик остальных клиентов.
2. Неисправности одного клиента (broadcast-storm, конфликты IP-адресов, не санкционированные DHCP-сервера клиента и т.п.) не должны влиять на работу как других клиентов, так и всей системы в целом.
3. Каждый клиент не должен напрямую получать доступ к ресурсам других клиентов (хотя, как специальный случай, можно предусмотреть и разрешение данного трафика, но с его централизованным контролем и/или управлением ).
4. Клиенты должны иметь возможность получения доступа к общим внешним ресурсам (которыми могут быть как отдельные сервера, так и сеть Интернет в целом).
5. Общие ресурсы должны также иметь возможность доступа к ресурсам клиентов (конечно при условии, что известен общему ресурсу известен IP-адрес ресурса клиента).
6. Адресное пространство для клиентов выделяется централизованно и его администрирование не должно быть чрезмерно сложным.

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

Вы бы могли поверить, что чуть более 15-ти лет назад Google размещался на порядка 100 серверах, которые сами же Ларри Пейдж (Larry Page) и Сергей Брин (Sergey Brin) монтировали в стойку и обвязывали между собой? При этом они использовали дешевые комплектующие, что б хоть как то снизить стоимость инфраструктуры их поисковой системы. Первые серверы интернет-гиганта имели довольно необычный вид, чего только стоили кнопки перезагрузки на передней панели каждого из них и довольно странный, но в тоже время интересный метод пробковой изоляции комплектующих от чего сами серверы получили название «Corkboard».

В блоге 45 Drives вышел достаточно интересный материал Роба МакКвина, который работает в R&D отделе компании. В нем идет речь об оптимизации полосы пропускания. Попробуем разобраться в этой истории и основных моментах, о которых рассказал Роб.

Рылся в своих старых записях и решил поделится с Вами инструкцией как просто и быстро поднять нормальный сервер для он лайн транслирования своего радио (mp3 файлы) и для ретрансляции внешних радиостанций.
Кому интересно прошу под кат.

На работе очень часто стоит вопрос — у нас DHCP сервер хорошо работает? Я работаю в internet провайдере, DHCP обеспечивает работу клиентской сети. Исторически сложилась следующая схема работы: DHCP серверов два, конфигурация генерируется на биллинговом сервере и с помощью rsync разливается на сервера. Используем Centos в качестве рабочей системы и ISC DHCP в качестве сервера. Никакого failover не настроено и не настраивалось — нет необходимости. Вполне достаточно, что сервера работают по идентичному конфигу. Используется привязка абонента к мак адресу, в случае смены оборудования у абонента есть возможность зайти в личный кабинет и указать новый мак. Генерация конфига выполняется раз в 5 минут, если у нового конфига изменилась md5 сумма — то сервис перестартовывает. Схема работает несколько лет, проблем нет.

Периодически возникали проблемы, что конфиг генерился синтаксически неправильным — и после рестарта сервис падал. Добавили в скрипт рестарта проверку синтаксиса (dhcpd -t), падения прекратились. Ну и со стороны билинга обвешано проверками — на наличие адреса, мака, и т.п.

Пару раз столкнулись с ситуацией, когда из сети приходят запросы, а ответы в сеть не доходят. Оказался виноват агрегатор, полечили. Все это время не хватало простого графического анализа — как работает DHCP сервер. Как показал опыт разборок с проблемами — банальным просмотром логов и оценкой, сколько каких сообщений принимает и отсылает сервер — можно уже примерно оценить наличие проблемы в сети. Ну и в принципе график можно показать ночному оператору с инструкцией — если здесь резкое изменение показателей — звони админам.

В этой заметке я хочу показать пример быстрой реализации корпоративного VPN сервера с поддержкой PPTP, L2TP (как с IPsec так и без), IPSec vpn с единой базой, который сможет работать с пулами адресов, разными группами пользователей, авторизировать пользователей как из LDAP, так и из локальной базы, опциональная настройка шейпирования как для групп, так и для отдельных пользователей с поддержкой windows, linux, osx, ios, android клиентов и все это на открытых решениях.
P.S. В данной заметке аспекты сетевой безопасности затронуты не будут, иначе она разрастется в огромный документ, с кучей нюансов в реализации, возможно о защите периметра и сетевой безопасности отдельно расскажу в следующий раз.
Кому интересно, добро пожаловать под кат.

Поставщики инфраструктурных решений и их партнеры безусловно стремятся оптимизировать свою бизнес-модель и перестраивают ЦОД и всевозможные подсистемы с учетом новинок. Задач здесь множество: от повышения качества предоставляемых услуг до минимизации негативного воздействия на окружающую среду.

В итоге все эти задачи «выливаются» в вопросы, связанные с энергоэффективностью, потреблением электроэнергии и стабильностью функционирования всех систем ЦОД.