Представим, что у нас есть приложение/сайт с достаточно высокой нагрузкой.

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

Как поступить, когда на сервер ежесекундно приходит большое количество народу? Ответ прост — nginx.

Приветствую, %habrausername%!

Сегодня я бы хотел поделиться своим опытом устранения проблем печати на терминальном сервере Microsoft.

Подробности под катом.

Многие сталкивались с таким явлением как DDoS атака методом HTTP флуда. Нет, это не очередной туториал по настройке nginx, хочу представить свой модуль, работающий как быстрый фильтр между ботами и бэкэндом во время L7 DDoS атаки и позволяющий отсеивать мусорные запросы.

В данной статье я бы хотел поделиться своим опытом настройки настройки сервиса сбора и визуализации статистики сollectd в связке с graphite. Первый используется как сборщик данных, второй — как хранилище с визуализатором.

Если вы испытываете нехватку физических портов на оборудовании сети передачи данных, в то время как перед вами встала острая необходимость завести второго интернет-провайдера или вывести часть серверов в ДМЗ используя оборудование Cisco Systems, тогда эта статья должна помочь с решением многим начинающим системным администраторам, а также тем, кто недавно приступил к работе с сетями передачи данных и с оборудованием Cisco в частности. Речь пойдет об архитекторе под названием Router-on-a-Stick.

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

Добрый день!

Мы храним картинки в CDN от Rackspace. Поставлена задача: выводить графики использования CDN, а именно количество объектов и занимаемое пространство.

Как по мне, лучший инструмент для выведения такого рода грфиков — Munin. Очень легко написать для него плагин на практически любом языке, да и данные можно выводить как угодно.

Я написал 2 плагина к Munin, которые по Rackspace API могут вам указать сколько у вас в сторадже файлов ну и их общий размер.

Вступление

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

Управление AWS осуществляется как с помощью веб интерфейса (AWS console), так и с помощью Command Line Tools. В консоли собраны все сервисы AWS, но функциональность настройки несколько обрезана. В командной строке же можно более гибко настроить тот или иной сервис, так же доступны закрытые в консоли функции.

Amazon Elastic Compute Cloud (EC2)

Описание

EC2 — это облачный сервис, предоставляющий виртуальные сервера (Amazon EC2 Instance), 2 вида хранилищ данных, а так же балансировщик нагрузки (Load Balancer).

Эта статья нацелена на читателей, которые начинают или только хотят начать заниматься программированием модулей ядра Linux и сетевых приложений. А также может помочь разобраться с прозрачным проксированием HTTPS трафика.

Небольшое оглавление, чтобы Вы могли оценить, стоит ли читать дальше:

1. Как работает прокси сервер. Постановка задачи.
2. Клиент – серверное приложение с использованием неблокирующих сокетов.
3. Написание модуля ядра с использованием библиотеки Netfilter.
4. Взаимодействие с модулем ядра из пользовательского пространства (Netlink)

P.S. Для тех, кому только хочется посмотреть на прозрачный прокси-сервер для HTTP и HTTPS, достаточно настроить прозрачный прокси-сервер для HTTP, например, Squid с transparent портом 3128, и скачать архив с исходниками Shifter. Скомпилировать (make) и, после удачной компиляции, выполнить ./Start с правами root. При необходимости можно поправить настройки в shifter.h до компиляции.

Всем хорош teamviewer, вот только в коммерческих целях он какой-то не бесплатный, о чем не устает напоминать… Да и вообще, не хорошо нарушать лицензию.

Но удобство запуска quick support впечатляет — клиент запускает маленькую программку, диктует циферки по телефону и вуаля, мы видим его рабочий стол. Никаких VPN, никаких пробросов портов и прочей предварительной настройки. Удобно же?

В качестве бесплатного аналога вполне подходит VNC, с call-back подключением вполне приемлемо, да вот только когда клиентов много, и компьютер к которому цепляются тоже не один начинаются те же проблемы (хотя и более решаемые). Идея teamviewer лично мне нравится больше. А если нравится, почему бы не сделать свою реализацию…

После скучного рассказа о подключении к кошкам переходим к настройке сети. В этот раз темы будут для новичков сложные, для старичков избитые. Впрочем сетевым аксакалам едва ли удастся почерпнуть что-то новое из этого цикла. Итак, сегодня:
а) аккуратно впитываем теорию о коммутаторах, уровнях сетевой модели, понятии инкапсуляции и заголовков (не пугайтесь — еще не время),
б) собираем спланированную в нулевой части цикла сеть,
в) настраиваем VLAN'ы, разбираемся с access и trunk-портами и тегированными Ethernet-фреймами,
г) соотносим текущие знания со стеком протоколов TCP/IP и моделью OSI (да, наконец-то мы ее коснёмся).



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

Есть в моем ведении несколько VPSов, на которых крутится… вообщем не моя зона ответственности, и потому крутится там то что крутится, в меру тормозит, в меру работает. И оказалось, что крутится на одном из них некий форум, и начал форум притормаживать. И захотелось разобраться…

Некоторое время назад меня попросили настроить в удаленном филиале простейшую балансировку трафика. Работают они, бедолаги, через ADSL, и отправка электронных писем большого объема (сканы документов) забивает им весь обратный канал, что приводит к проблемам в работе с офисными онлайн-программами через VPN.
В качестве шлюза у них используется Linux (Fedora). До этого я пару раз видел, как подобная балансировка настраивается через ipfw на FreeBSD, а так как знаю механизм iptables достаточно хорошо, не ожидал особых проблем. Но поискав в Интернете, я был неприятно удивлен тем, что iptables мне тут совсем не помощник. И знания о порядке прохождения пакетов через его таблицы и правила мне почти не пригодятся. Нужно изучать tc из пакета iproute2.

Неожиданно для себя, я потратил два дня, для того чтобы более-менее разобраться в балансировке трафика средствами iproute2. Сначала попалась не самая лучшая для новичка статья про HTB(здесь). Различные примеры из Интернет тоже порой вводили в ступор, так как в них часто не было описания конкретных опций или смысла их применения. Поэтому я и попытался собрать полученные мною знания в одну статью, а главное описать все на доступном для новичков уровне.

Последнее время на Хабре всё больше статей на тему «Умный Дом», «Сделай Сам», и меня это радует. Внесу и я свой скромный вклад в развитие цивилизации. Добро пожаловать в мир умных вещей!

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

1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.

2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.

Хочу поделиться с хабрасообществом опытом создания веб сервиса для конвертирования видео и сохранения в облачном хранилище. Сразу оговорюсь, сервис написан для внутреннего пользования одной европейской компании, и уже работает более 6 месяцев. Одним из направлений компании является продукт WebTv. Было очень проблематично на каждом новом сайте разворачивать структуру для конвертирования видео, и зачастую эти процессы очень тормозят работу сервера.
Было решено создать сервис, который бы удовлетворял следующим требованиям:

• Легкая интеграция с любым сайтом.
• Реализовать процесс конвертации более одного видео файла в одно и то же время.
• Реализовать процесс сбора видео с ftp, IMAP и просто напрямую получать видео файл через HTTP POST.
• Опционально при помощи дополнительных параметров, уметь вращать видео, вещать водные знаки и т.д.
• Реализовать безопасную систему авторизации во фронте, где юзеры могут видеть, какие данные уходят на видео сервис помимо видео файла.
• Отправлять готовые результаты на Amazon S3.
• Хорошенько обрабатывать ошибки, и оповещать об этом клиентский сервис.

Возникла как-то на работе потребность организовать в сети хранилище для документации всякой разной. Требования: надежность, небольшой размер, объем в несколько террабайт. Мой выбор остановился на сетевом хранилище (Network Attached Storage) Iomega StoreCenter Ix2-200. В процессе исследования рынка выяснилось, что на этом устройстве используется урезанный вариант Debian Lenny, и есть возможность установить полноценный Debian Squeeze. Тем самым получить все возможности, предоставляемые данной ОС.

Итак, устройство было закуплено, я обложился документацией, найденной в интернет и приступил к установке ОС Debian Squeeze для архитектуры armel. К сожалению, доступная документация оказалась на английском, не полной и не точной, в общем был простор для размышлений. К тому же для первоначальной загрузки и переустановки ОС потребовался достаточно специфичный кабель RS-232.

В итоге под катом описан мой эксперимент (успешный), переведены необходимые куски чужих инструкций, и представлена полученная мною экспериментальная информация.

Какое-то время назад я описал для хабрасообщества идею виртуальной корпорации — новой схемы трудовых отношений в цифровую эпоху.

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

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

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

Доброго времени суток.

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

Почти всегда на ночь (или утром, со словами «Что? Рассвет уже?») я включаю на ноутбуке фильм или сериал. Чтобы бубнило и успокаивало. Недавно заметил, что совсем не уменьшаю яркость при включении. Свет светит в глаза, мешает уснуть. Решается поворотом на другой бок или уменьшением яркости, конечно, но я слишком ленив, чтобы искать Fn+уменьшить яркость или установить и вывести апплет яркости. Уменьшение яркости при неактивности ставить не захотел, потому как это меня раздражает (пьешь себя кофе и смотришь код, тут резко до нуля так хрясь). Вспомнил про свою старую Nokia E70 (ох и шикарный телефон был), в котором был индикатор освещённости. Подумал, что такой датчик может заменить и обычная камера.

Введение

Эта статья – скорее из разряда «для самых маленьких», чем «для умудренных опытом», но она призвана повышать профессиональную культуру системных администраторов.
В силу специфики работы мне «по наследству» достается самый разнообразный облачный ад, который приходится разгребать, оптимизировать, приводить в чувство и делать прозрачным и красивым. Эти заметки, пожалуй, иллюстрация к тем моментам, которые вообще недопустимы в системном администрировании.
В причинах, которыми порождаются эти анти-паттерны, можно разбираться очень долго: дедлайны, законы и темпы бизнеса, да и просто идиотизм, наконец. Но цель статьи другая. Мне бы хотелось породить конструктивную дискуссию. А вот уже её результаты и являются основной целью статьи.