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

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

Мы в Backblaze предлагаем нашим клиентам неограниченное хранилище всего за $5 в месяц, поэтому нам пришлось выяснить, как хранить сотни петабайт клиентских данных надёжным масштабируемым образом, при этом сохраняя цены низкими. Посмотрев на несколько коммерческих решений с неоправданно высокими ценами, мы решили строить наши собственные нестандартные контейнеры хранилища Backblaze (Backblaze Storage Pods): 67-терабайтные 4U-серверы за $7867.

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

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

В этом году мы опубликовали две статьи, связанные со сравнением функциональности маршрутизаторов и межсетевых экранов компании Cisco, а также с обзором разделения control и data plane в сетевом оборудовании. В комментариях к этим статьям был затронут вопрос производительности сетевого оборудования. А именно как зависит производительность маршрутизаторов Cisco разных поколений от включения на них тех или иных сервисов. Так же обсуждалась тема производительности межсетевых экранов Cisco ASA. В связи с этим возникло желание посмотреть на эти вопросы с практической стороны, подкрепив известные моменты цифрами. О том, что получилось и, что получилось не очень, расскажу под катом.

Приводится опыт создания и эксплуатации ИТ системы компании, состоящей из примерно 10 сотрудников. И некоторые рассуждения на тему: куда развиваться нашей ИТ системе дальше.

Это взгляд со стороны директора компании, а не ИТ специалиста, без углубления в технические вопросы практической реализации.

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

Задача создания своей ИТ системы была нами поставлена и решена в 2011 году. Прошедшее время полностью подтвердило правильность принятых тогда решений.

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

Основной используемый в компании софт – обычный офисный пакет, 1С бухгалтерия. Что тогда не требовалось, так это: собственный почтовый сервер, IP телефония.

Естественно выбранное решение сравнивалось прежде всего с обычной одноранговой сетью.

В итоге была выбрана структура с терминальным сервером (на ОС WINDOWS), организованного на простом специализированном сервере (не самосборка).

Введение

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

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

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

Итак — эти 7 правил:

1. Скука убивает
2. Прежде чем начать, выясните точно для себя, какие действия вы ожидаете от читателя, осилившего ваш труд
3. Пишите в соответствии с правильно сформированной структурой
4. Избегайте неоднозначных местоимений
5. Ясность = иллюстрации + слова
6. Когда имеете дело с понятиями, концепциями и т.п., используйте логическую иллюстрацию и пример
7. Не опасайтесь переделок

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

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

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

Приветствую!

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

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

Сейчас же, решили сравнить производительность СХД начального уровня и массива на контроллере P410. Напомню, что интересующие нас параметры: IOPS — количество дисковых операций в секунду (чем больше, тем лучше) и latency — время обработки операции (чем меньше, тем лучше).

Всем привет! Прошлая статья про прозрачное проксирование HTTPS с помощью Squid'a была вполне успешной. Приходило по почте множество отзывов об успешной установке данной системы. Но также и поступали письма с просьбами о помощи. Проблемы были вполне решаемыми. Но не так давно обратилась ко мне одна коллега с просьбой о помощи в установке этой системы на х64 архитектуре (Debian). Тут мы озадачились. Во-первых, оказалось, что прошлая статья непригодна для этого по причине отсутствия нужных исходников в репозитории Debian (там теперь 3.5.10). Найти нужные в первой статье Debian'овские исходники не удалось, а checkinstall выдавал странные ошибки. Во-вторых, хотелось более универсального решения, которое бы без проблем работало и на х64, и на х86, и (по-возможности) на других дистрибутивах. Решение было найдено. Получилось небольшое дополнение к предыдущей статье + некоторые уточнения. Данная инструкция позволяет скомпилировать как х86, так и х64 версии Squid'a и создать соответствующие пакеты. Инструкция будет разбита на несколько пунктов и подпунктов. Если интересно, идем под кат:

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

Но объективного сравнения в лоб с локальной производительностью Quadro я не нашёл.

У нас в конфигураторе давно открыты модели серверов с поддержкой технологии GRID, ведь карты GRID (ранее VGX) появились уже давно.

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

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

— Корпус CSE-745TQ
— Материнская плата X9DR3-F
— ЦП 2шт E5-2650
— ОЗУ 128Гб
— 8 SAS-дисков в RAID5

Оборудовали серверы картами GRID K2. В качестве гипервизора выбрали VMware. Установили специализированное ПО на виртуальные машины и провели тестирование.

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

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

Для начала, провел тесты локально на Windows 7 — получил результаты производительности Quadro K5000 и K420. Так как карта GRID K2 включает в себя 2 чипа, аналогичных чипу K5000, эти данные мне понадобятся для сравнения производительности виртуальных машин в различных режимах деления графических процессоров.

Мне попала в руки одна из новых IP АТС от Grandsteream UCM6108 и я спешу поделиться своими впечатлениями. Сразу скажу, что это уникальный по способности к конкуренции продукт, так как внутри в основе код уже достаточно развитой open source платформы Asterisk. Это дает возможность производителю вообще отказаться от такого понятия как лицензирование портов и функционала, а количество телефонных функций уже с первыми прошивками очень большой. За доступную цену, которая, кстати сказать, ниже цены на сервер или компьютер, на котором можно поднять бесплатную IP АТС, пользователь получает готовую к работе железку, весь имеющийся функционал без закупки дополнительных лицензий и простоту конфигурирования.

Предыстория

На тот момент, когда я первый раз попробовал заменить в ИБП старый аккумулятор ёмкостью 7Ач на старый автомобильный аккумулятор номинальной ёмкостью 65Ач, я ещё не знал, почему этого нельзя делать, и как это может навредить здоровью аккумулятора, самому ИБП и людям, проживающим в одном помещении с ним.

Доработка бесперебойника не заняла много времени, но профит был заметен сразу же. Сто-ватная нагрузка в виде домашнего «сервера» продержалась порядка двадцати часов без внешнего питания, хотя раньше 10 минут — это был предел, которого хватало разве что на корректное завершение работы. Более длительных отключений за время эксплуатации данной модификации замечено не было, а подключение интернета по технологии GPON позволяло серверу оставаться в сети даже при масштабных отключениях электроэнергии.



Но это было давно. А год назад мне случайно попалось на глаза объявление о продаже нескольких бывших в употреблении ИБП APC 3000 за смешные деньги, 4000 рублей за штуку, без аккумуляторов, но рабочие. Немного подумав, решил что надо брать, причём сразу два, правда к моменту покупки цена успела подняться до 5000 рублей за штуку, но меня это не остановило, ведь в магазине за те же деньги предлагали лишь варианты на 1кВт, да и то от всяких noname фирм с не очень лестными отзывами и модифицированным синусом.

Мы продолжаем серию статей про взаимодействие Linux и Windows. Эта статья посвящена управлению доступом к серверам Samba из домена AD.

В отличие от предыдущих статей, где в качестве примера использовалась тестовая сеть, эта статья базируется на реальной, «боевой» сети Московского энергетического института. В сети МЭИ зарегистрировано около 25000 пользователей. Сеть объединяет все учебные корпуса МЭИ с более чем 4500 рабочими станциями. Мы рассмотрим настройку доступа к серверу Samba, предоставляющему пользователям следующие услуги:
•доступ к персональному каталогу пользователя;
•доступ к общим каталогам;
•управление доступом как с использованием средств Samba, так и с использованием средств Windows.

CTB Locker — очень хорошо продуманный и опасный вирус. Писать о нем не буду — информации об этом вирусе в интернете очень много.

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

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

Я не агитирую пользователей сообщества платить злоумышленникам (я противник этого), но, возможно, этот небольшой мануал кому-то поможет.

Далее я опишу пошагово, как платил плохим людям за расшифровку клиентских данных.

История

Внедрение Linux в ПриватБанке началось в 2007 году. За это время был пройден большой путь и хотелось бы поделиться с сообществом своим опытом внедрения. На данный момент мы достигли следующих показателей: более 36500 рабочих мест с ОС Linux в 4000 отделений, расположенных в 5 странах.
В 2007 году за основу был взят ASPLinux 11.2. Со временем для альтернативы были выбраны другие дистрибутивы — Fedora, openSUSE, Ubuntu. Позже стала очевидной необходимость создания собственного дистрибутива и системы управления рабочими станциями. Разработка началась в январе 2012 года. Для основы был выбран Ubuntu 12.04 LTS с рабочим окружением Gnome Classic (no effect). Основные аргументы: Ubuntu — самый распространённый десктопный дистрибутив последних лет; обширное комьюнити, где проще найти решение возникающих проблем; именно его в качестве основы внедрения выбрал Google, много примеров внедрения в государственных и муниципальных учреждениях Германии, Франции. Выбор системы управления остановился на Puppet.
В июне 2012 года стартовал переход и к январю 2013 на корпоративную ОС были переведены уже около 95% ПК. Такая скорость перехода обусловлена тем, что сотрудники уже имели опыт работы в Linux.

Основные задачи, которые удалось решить благодаря текущему внедрению:

• cущественная экономия ресурсов при поддержке ОС на рабочих местах сотрудников;
• поддержание программного обеспечения в актуальном состоянии;
• возможность оперативного применения критических обновлений (до 1 часа на всех ПК);
• cбор и анализ статистической информации о парке ПК и периферии;
• создание системы проактивной реакции на сбои (Event Manager).

Дальше более детальное описание компонентов нашей реализации.

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

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

В ходе деятельности любой организации, у нее возникают и исчезают временные союзники, она дружит и разрывает дружбу с партнерами, она реорганизуется, поглощает другие организации и наоборот, разделяется на несколько. С точки зрения ИТ часто возникает необходимость в создании общих ресурсов, доверительных отношений между лесами Active Directory, в налаживании vpn-туннелей сеть-сеть и прочих «объединительных» процедурах. Ниже я рассмотрю одну такую процедуру, копирование контактных сведений о пользователях чужого доверенного домена.

Некоторое время назад в компании была развернута терминальная ферма.
Первым делом в неё были выселены пользователи некой желтой программы.
После чего отдел поддержки желтой программы спросил меня, можно ли отсылать сообщения пользователям фермы всем сразу. XaocCPS посоветовал мне играться в сторону WPF. Нужный скрипт был написан, но его работой я неудовлетворился:
1. Надо ставить внешний компонент PowerShellPack.
2. Компонент ставиться на сервера фермы (х64) отказался.
3. Распространять такое решение из за пункта 1 всем желающим не очень удобно.

Xaegr подсказал что я могу избавиться от прослойки WPF.
Писать можно, можно даже писать красиво. Скрипт выполняется везде где есть .Net Framework — XP, Win7 и скорее всего пойдет даже на х64 серверах фермы.
Как писать — под катом.

UPD по просьбам скрипт выложен на SkyDrive, ссылка в конце