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

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

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

Читая статьи на хабре о веб-сокетах, сильно захотелось что-нибудь написать на них. После долгих поисков я выбрал Tornado Web Server, в качестве сервера, ведь он написан на Питоне, да и он похож на GAE.

В рамках моего дипломного проекта мне предложили создать систему формирования проектных команд на основе технологий семантической паутины. Так как я уже переболел голым PHP, SQL, ZF, и имел опыт программирования на Ruby on Rails, ознакомившись с существующими гемами и решениями для работы с RDF, решил писать на нём, т.к. не очень люблю яву (да простят меня ява-разработчики), хотя она и является самым передовым языком в области semantic web, intelligent agents, data mining.

Возникла достаточно неординарная идея: виде средства сетевого кеша взять не MemCache, а MongoDb и сравнить их производительность. Но для представления и сравнения показателей этих двух «механизмов кеширования» взяли еще и другие средства, позволяющие ускорить работу нашего App (APC, RamFS, TmpFS, XCache).
В статье приведены данные и графики сравнения этих механизмов с описанием и рассуждением полученных данных и графиков.

Буквально сегодня увидел у себя в Facebook сообщение о том, что команда из 10gen, занимающаяся разработкой, ставшей причиной долгих и упорных споров, MongoDB, набирает добровольцев для перевода актуальной документации к этой БД.

Вот полный список языков, на которые планируется перевод:

• Chinese
• French
• German
• Hebrew
• Hungarian
• Indonesian
• Italian
• Japanese
• Korean
• Portuguese
• Russian
• Serbian
• Spanish
• Swedish
• Vietnamese