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

Существует немало систем мониторинга, которые выполняют активную проверку сети и сетевых сервисов по протоколам ICMP и SNMP. Быстрый и неправильный ответ – очевиден. Достаточно настроить волшебную систему мониторинга, и наступит полное счастье. Вся обманчивость этого заблуждения понимается со временем. Сначала выясняется, что обнаружение аварий происходит только на тех сервисах, которые поставлены на мониторинг. Хорошо, если удалось накрыть хотя бы основные сервисы. Остальные, увы, будут ставиться на мониторинг в результате горького опыта и ценой запоздалой реакции. Чуть попозже начинается мистика. Что-то явно работает не так, есть жалобы, но система мониторинга говорит, что все в порядке. В чем причина?

Доброго времени суток, хабраюзер! Мы продолжаем цикл статей и видео, посвященных
российскому Центру обработки данных компании Intel и рассматриваем сегодня систему
свободного охлаждения или free-cooling.

Попробую продолжить начатую мной тему методологии и алгоритма функционирования QoS в Cisco. В этой статье будет описано по каким принципам можно разделить и маркировать трафик на 2-3 уровнях модели OSI на пошаговых примерах. Кому интересен данный вопрос прошу под кат.

Добрый день, в данной статье хотел бы немного рассказать о методе построения правил QoS в устройствах Cisco. Для начала хочу дать краткое определение понятию QoS.
QoS — это способность сети, обеспечивать улучшенное обслуживание сетевого трафика независимо от выбранных технологий, включая Frame Relay, ATM, Ethernet или IP сеть с маршрутизацией.

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

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

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

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

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

В этой статье я опишу что из себя представляет технология доступа в Интернет IPoE, которой на самом деле не существует. А также расскажу про схему Client-VLAN и про опцию 82 DHCP (DHCP Option 82), которые стали неотъемлемой частью этой несуществующей технологии. Все это, конечно же, с технической точки зрения и с примерами конфигов.

Synapse — это весьма приятный лаунчер, с довольно интересными плюшками.

Добрый день, коллеги!

судя по многочисленным вопросам на форуме (ссылка в конце поста), от слушателей и коллег, работа NAT на маршрутизаторах Cisco (firewall'ы я опущу, Fedia достаточно подробно его работу расписал в своей серии статей про Cisco ASA) плохо описана, поэтому я попробую описать свой опыт и свое понимание данной технологии в большинстве ее ипостасей. Не претендую на всеобъемлющее описание и 100% точность, но кому интересно — велкам под кат.

Просмотрев большинство тематических постов на хабре был безмерно удивлён тому факту, что крайне скудно освещена тема использования ОС Unix/Linux на службе интернет провайдеров (Internet service provider). Данной статьёй я частично попытаюсь восполнить данный пробел.

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

Будут рассмотрены следующие средства: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более что это отдельная обширная тема.

Тонкий клиент (англ. thin client) в компьютерных технологиях — бездисковый компьютер-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер (Wikipedia ).

Если проще, то тонкий клиент – это недокомьютер, который загружает легкую операционную систему (обычно используется Linux, в обзоре возьмем это за априори) и соединяется с терминальным сервером.

Обычно тонкие клиенты создаются для экономии на железе и ПО, в редких случаях по иным соображениям.



В этой статье я постараюсь сделать краткий обзор WTWare, являющегося Linux дистрибьютивом, разработанным специально для создания тонких клиентов.

Открываем

Открыть вкладку можно тремя разными способами, самый простой и интуитивный :tabnew в нормальном режиме, он откроет новую вкладку с пустым буфером. Можно сразу открыть вкладку с файлом, передав его имя как параметр

:tabnew futuri.co

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

vim -p habra.sh habr.py

Проведенный опрос довольно недвусмысленно показал, что такая аббревиатура хабрасообществу известна мало. Наверняка еще меньше слышали об ECM, CRM, SCM, CPM, BPM и других страшных трехбуквенных аббревиатурах.

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

Вот есть рынок ERP-систем. Большой, вроде как растущий рынок (сейчас, правда, очень сомнительно, что он растет). Ежегодно какие-то умные дядьки его оценивают, публикуют страшные для восприятия цифры. На рынке есть некое количество неких программных продуктов, количество которых поддается счету. Это и есть продукты этого рынка. А что могут эти продукты?

После вот этого поста о внедрении ERP систем, я решил тоже написать по этому поводу. Человек, лично руководивший хотя бы двумя-тремя проектами, никогда так не напишет. Этот пост я встречал как-то в жж в качестве комментария. Но одно дело комментарий и совсем другое дело – пост. Все случаи свалены в одну кучу.

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

Я попытаюсь раскрыть эту проблематику более полно и точно.

Да, понятно, что в России с успешным внедрением ERP систем дела обстоят не так, как на Западе. Хотя, и в Датском Королевстве, уверен, не все ладно.

О чем это он?

Это продолжение вчерашней статьи о электронном документообороте. Я покажу, как мы реализовали, простую систему подачи заявок. Использована CMS Drupal, и несколько дополнительных модулей. На рисунке можно посмотреть, как выглядит система подачи заявок.


(Кликабельно)

Я уже несколько лет занимаюсь внедрением систем электронного документооборота (СЭД). Начинал свой профессиональный путь в небольшой IT-компании, в которой работало около 10 человек. Компания внедряла коробочные решения СЭД в различных органах государственной власти. После этого я работал еще в нескольких компаниях, какие-то из них были очень даже серьезными, с серьезным подходом к проектам и серьезными бюджетами. Но независимо от масштабов компании и «раскрученности» внедряемой платформы, большинство моих проектов были нецелесообразными.
Это не значит, что все проекты были убыточны. Какие-то из них имели технико-экономическое обоснование, а какие-то даже ему соответствовали, и были действительно экономически выгодными. Но экономическая эффективность это не единственная величина определяющая целесообразность проекта.