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

В этом посте я расскажу о новых серверах DELL PowerEdge серии C (С – от Cloud), а также о том, как благодаря новому оборудованию мы удвоили емкость нашей площадки в ДЦ и при этом сохранили затраты на эксплуатацию на прежнем уровне.

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

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

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

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

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

Так что следующим шагом стал просмотр готовых вариантов в сети.

Поиск

Шаблоны для CMS не подходят хотя бы потому, что CMS не будет. И такие шаблоны чаще всего рассчитаны на более сложные сайты. И они не будут радовать посетителей с мобильными устройствами.

Хотя, сейчас появились шаблоны с адаптирующейся разметкой (responsive design), которые и вызвали у меня интерес. К сожалению, большинство найденных решений оказались платными, что не удивительно, учитывая объем работы, который проделывают их авторы.

Доброго времени суток, коллеги!
Все из вас не раз сталкивались с проблемой анализа уязвимостей на целевой системе. Основным камнем преткновения которой является разрозненность подачи данных вендороми.
В одном месте вы можете найти саму уязвимость, в другом ее оценку, в третьем необходимые условия для проверки и в четвертом ссылку на патч.
Специально для решения этой проблемы существует язык описания уязвимостей OVAL

Этот пост является продолжением предыдущего. Мониторинг прогнозированием – не стандартный метод мониторинга. Поэтому и оповещения необходимо использовать не совсем стандартные. Рассмотрим, как это делается и почему именно так.

В начале месяца вышел релиз Red Hat Enterprise Linux 6.2, в котором особое внимание уделено хранению данных. Теперь понятно почему — Red Hat выходит на новый для себя рынок, рынок больших данных («big data»). После того, как Red Hat купил Gluster, я опубликовал некоторые свои мысли о том, для чего сделана это покупка. Но я не мог даже представить, что новый продукт у Red Hat появится всего-лишь спустя два месяца, после анонса сделки..

Одна из причин, почему Red Hat станет первой Open Source компанией с оборотом в миллиард долларов, это то, что она занимается не только дистрибутивом Linux, но и многими другими вещами, связанными с Linux, такими как облачные вычисления, виртуальные десктопы (VDI), Java Enterprise и теперь, с выходом Red Hat Storage Software Appliance, управлением большими данными.

Доброе время суток!

Так уж сложилось, что я занимаюсь всякими разнообразными push технологиями с использованием Tornado. Чуть ранее описывал Tornadio2, серверную реализацию протокола socket.io поверх Tornado.

Теперь хочу представить похожий проект — sockjs-tornado.

Для тех кому не очень интересно, есть другая полезная информация: сравнительное нагрузочное тестирование PyPy 1.7 против CPython 2.6.6, sockjs-node и socket.io (оба на node.js 0.6.5). Все под катом :-)

Введение

Недавно я описывал созданную мной систему мониторинга транзитного VoIP методом прогнозирования. Самым сильным плюсом данного метода в задаче мониторинга транзитного VoIP является то, что нет необходимости выставлять критерии того, что считать нормальной работой величин, находящихся под мониторингом, а что – потенциальным сбоем.
Ядром системы является rrdtool, в котором реализованы прогнозирование методом Хольта-Винтерса и механизм выявления аберраций.
Мониторинг методом прогнозирования можно использовать не только для VoIP, но и для любого другого типа трафика, а так же, для величин, которые изменяются во времени с некой прогнозируемой цикличностью. В отличие от стандартных методов, при мониторинге с помощью прогнозирования не осуществляет мониторинг состояния величин, находящихся под мониторингом, зато осуществляется мониторинг динамики изменения их состояний во времени.
Если вам интересна математика прогнозирования рекомендую прочесть. Чтобы быть хоть немного в курсе темы, прочтите главу “Метод прогнозирования реализованный в rrdtool” моего предыдущего поста.

Первая часть.

Система пляжного управления компанией или автоматизированный мониторинг ключевых показателей успешности.

Представьте такую ситуацию. Вы инвестировали и основали бизнес. В сумме инвестированный капитал составил 10 млн. рублей.
Утрируем до «идеальной ситуации», когда бизнес работает как хорошо отлаженный механизм, приносит доход и не требует вашего участия (мечта любого собственника бизнеса). Можно загорать на пляже и тратить получаемые деньги.
На протяжении года менеджмент компании исправно выплачивает вам хорошие дивиденды, которых хватает, чтобы беззаботно проводить время в собственное удовольствие.
Наступает страшный день, когда вдруг не выплачивают причитающиеся средства и аргументируют это различными текущими трудностями. И это повторяется снова и снова, месяц за месяцем.
Когда вы вернулись и разобрались с делами, оказалось (опять утрирую), что бизнес работал в убыток, а дивиденды выплачивали, размывая активы. Не осталось ни активов, ни вложенных капиталов, ни, в принципе, и самого бизнеса. Возникает извечный русский вопрос: Кто виноват и что делать?

Для того, чтобы такого не случалось, необходимо контролировать состояние активов и успешность работы бизнеса. Вопрос как это можно делать сидя на пляже?

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

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

Любому инженеру, управляющему парком серверов Badoo – самой популярной сети знакомств в интернете, не хочется даже вспоминать о том, что когда-то приходилось править вручную конфигурации DHCP-сервера, собирать образы для сетевой PXE-загрузки… Мы хотим рассказать вам, где и как в нашей компании успешно используется программное решение xCAT.

Описание проблемы

Представим среднестатистический высоконагруженный сайт. Обычно на таких сайтах между backend'ом и DB ставят прослойку кеша. С увеличением количества посетителей, вероятность того, что несколько пользователей одновременно наткнутся на "протухший" кеш увеличивается. Если такое случается, то нагрузка на backend и DB возрастает, что в свою очередь увеличивает время обработки запроса и увеличивает вероятность возникновения подобной ситуации. Вот такая вот система с положительной обратной связью:Маленькие красные горбики — это "затупившие" на множественном обновлении кеша запросы. Эта статья будет описывать один из подходов к решению проблемы на примере(patch attached) связки PHP/APC, однако теоретическая база применима к любому языку и системе кеширования.

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

Как развернуть несколько сотен серверов в географически удаленном дата-центре при отсутствии физического доступа к оборудованию? Как компания Badoo решает такую задачу?
Мы расскажем вам об этом на следующем примере.

Ниже пойдет речь о самом первом этапе конфигурирования серверного оборудования; о том, как быстро и в срок мы выполнили конкретную задачу, а не о написании оптимальных скриптов. В случае, если данная тема покажется вам интересной, мы с удовольствием расскажем и об установке ОС на сервера и настройке рабочего окружения, в чём тоже имеются свои тонкости.

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

В программу вошли три компонента:

• новые сверхэкономичные серверы на процессорах с пониженным энергопотреблением — вначале на ARM, а затем и на Intel Atom, чипах AMD и других вендоров. На базе таких серверов строится платформа HP Redstone, позволяющая использовать свыше 2800 серверов в одной стойке;

• исследовательская лаборатория HP Discovery Lab, с помощью которой заказчики смогут тестировать решения для новой платформы;

• партнерская экосистема HP Pathfinder, созданная для развития проекта Moonshot. На данный момент в числе партнеров HP здесь называются AMD, ARM Holdings, Calxeda, Canonical и Red Hat.

Когда я начинал этот проект, многие говорили — ну о чем же ты там будешь писать, ведь все знают, что в «рашке» все только рушится, ничего не производится, а если что и открылось новое иногда, так это исключение подтверждающее правило, это все «вопреки» да и то исключительно для распила.

Но я наивный, как говорят мне некоторые, поэтому я был уверен, что писать на сайте будет о чем. И что такая идея — первый сайт пишущий о реально сделанном в России — он найдет свою аудиторию. Так и случилось.

За год на сайте появилось крепкое сообщество. Первые месяцы мне приходилось самому искать новости, добавлять на сайт, писать обзоры. Теперь это делают пользователи сайта. Посещаемость выросла уже до 6000 человек в день, и продолжает расти примерно по 30% в месяц. В будний день на сайте появляется до 30-40 новых записей, большая часть из них о том что уже сделано.

Но главным нашим достижением, наверное, стал ответ на вопрос, а сколько же производств открывается в России.

Часть 1
Часть 2
Часть 3

В четвертой части, как и было обещано, рассмотрим ограничения и недостатки Asterisk как голосовой платформы и особенности его взаимодействия с VoiceNavigator.
Голосовая платформа – это программно-аппаратный комплекс с функциями синтеза и распознавания речи, позволяющий создавать решения, направленные на оптимизацию работы контакт-центра, усовершенствование работы с клиентами и построение систем голосового самообслуживания.

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

Среди больших и известных голосовых платформ, использующихся в колл-центрах для построения СГС, стоит отметить Avaya Voice Portal, Genesys Voice Platform, Siemens OpenScape CCVP, Cisco Unified CCX, Voxeo, Voxpilot.
Информации в Рунете очень не много, как и специалистов по данным продуктам с соответствующим уровнем компетенции. Используются в больших колл-центрах, стоимость соответствующая, и доступна она только для больших компаний.
Если будет интерес к какой-то из платформ, готов написать о них отдельно.

Два основных недостатка, существующие в Asterisk+UniMRCP — это отсутствие поддержки VoiceXML и неработающий barge-in для синтеза речи.

Недавно один из заказчиков TestLab² пожелал узнать, как будет работать его инсталлятор (с закачкой всякого на лету) на разных каналах. Внезапно первые подходы показали, что нам везет и обычные edge, umts и wimax-каналы (не говоря о проводных) в нашей округе как-то уж очень хорошо работают.
Чтобы создать тяжелые условия мы нашли и применили специализированный инструмент WANem, о котором я расскажу под катом.

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

1) Кэширование результатов выполнения запросов

• плюсы: высокая скорость доступа к данным
• минусы: требует компромисса между актуальностью данных и скоростью доступа, т.к. данные в кэше могут устареть, а удалять старые данные из кэша с последующим кэшированием новых — это дополнительные задержки и нагрузка на систему

2) NoSQL решения

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

Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).

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

Еще в начале 80-х комитет ISO выделил основные компоненты системы управления сетью. Модель получила название FCAPS. По версии ISO, для успешного управления сетью надо уметь управлять отказами (F), конфигурацией оборудования и сервисов (C ), собирать и обрабатывать статистику по потреблению услуг (A), оценивать производительность (P) и централизованно управлять безопасностью (S). Прошедшие три десятка лет не добавили ничего принципиально нового, и все задачи управления сетью так или иначе прыгают вокруг основных составляющих.

Коммерческие комплексы подобного рода весьма дороги и далеко не безгрешны, а среди open-source систем присутсвовал явный и откровенный пробел, что просто подталкивало на разработку своего велосипеда. В результате обобщения нашего личного опыта по созданию и эксплуатации сетей, после долгих проб и ошибок появилась система NOC

Система Rspamd разрабатывается как основная система фильтрации спама в Рамблер-Почте. Однако же, изначально я планировал сделать систему, которая бы не уступала по возможностям, гибкости и качеству работы Spamassassin'а, однако была бы лишена основных его недостатков: чрезмерного использования регулярных выражений, слабой оптимизацией и общей задумчивостью работы, а также сравнительно неточной статистикой. Так созрела идея rspamd — системы, ядро которой было бы оптимизированно для фильтрации большого потока писем, которая была бы легко расширяема и использовала бы более совершенные алгоритмы статистики. Ядро rspamd написано на Си и использует событийную модель обработки сообщений (основанную на libevent). Расширяется rspamd путем написания плагинов и правил на языке lua. Сам проект с самого основания был Open Source (под BSD лицензией) и сейчас расположен на bitbucket.

Три дня назад Cisco заявила об очередном сокращении штата, в этот раз — на 6 500 сотрудников и намерении продать фабрику в городе Хуарез в Мексике гиганту Foxconn, что лишит работы на американскую компанию еще 5 000 человек. Все эти события следуют за решением компании остановить производство камеры Flip и свернуть разработку социальной/видео платформы Eos.

Прошло всего несколько лет с того момента, как Cisco расширяла свой бизнес в новые рынки, сжигая миллиарды долларов на слияниях и поглощениях, съев такие компании, как WebEx, Tandberg и Flip. Теперь движение резко сменило направление — что же случилось?

Слишком большой успех

Нынешнее положение Cisco — это классическая история, когда кто-то становится жертвой собственного успеха. В момент апогея пузыря дот-комов, Cisco по капитализации обошла Microsoft и стала самой дорогой компанией в мире. В конце-концов, это неудивительно, ведь Cisco продавала оборудование, за счет которого существовала всемирная сеть. Некоторый успех был достигнут и в области корпоративных VOIP продуктов, куда расширяла свое влияние компания, но к этой теме мы вернемся снова чуть ниже.

Взрыв пузыря сказался и на бизнесе Cisco. Всего через год после того, как капитализация компании превысила оную Microsoft, Cisco уволила 11% собственной рабочей силы. Проблема была двухсторонняя: во-первых, компания владела почти целым рынком, поэтому если рынок начинал падать, то же самое происходило и с Cisco; во-вторых, инвесторы хотели роста, а рынок корпоративного сетевого железа казался уже огромным, фактически — он вырос до максимальных размеров. По случаю, в марте 2007, Cisco прикупила WebEx и тогда же появилось первое сообщение о том, что гигант уже владеет долей от 70% до 90% на рынке свитчей и роутеров, но инвесторам, как это часто бывает, было мало и они требовали еще большего роста.