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

Первый способ — это при помощи SNMP-запросов, с отправкой которых Zabbix замечательно справляется. Так можно вытащить и загрузку сетевых интерфейсов, и загрузку процессора, памяти. Поверх этого, производители сервера могут выдать нам по SNMP еще много информации о состоянии железа.

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



Что делать, если того, что мы хотим контролировать через Zabbix нет в списке возможностей Zabbix агента? Ждать пока это имплементируют разработчики в следующем релизе? Не обязательно.

Тех, кто использует или собирается использовать Zabbix в промышленных масштабах, всегда волновал вопрос: сколько реально данных сможет Заббикс «переварить» перед тем как окончательно поперхнется и подавится? Часть моей недавней работы как раз касалось этого вопроса. Дело в том, что у меня есть огромная сеть, насчитывающая более 32000 узлов, и которая потенциально может полностью мониториться Заббиксом в будущем. На форуме давно идут обсуждения о том, как оптимизировать Zabbix для работы в больших масштабах, но, к сожалению, мне так и не удалось найти законченное решение.

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

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

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

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



В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

Продолжение.
Предыдущие части: 1-3, 4-6

7. Связь один-ко-многим.

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

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

(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)

Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.


Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице B.

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

Другие части: 4-6, 7-9, 10-13, 14-15.

Руководство по проектированию баз данных.

1. Вступление.

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

Привет!
В этой статье я хочу рассказать вам про мой путь из офиса во фриланс: мотивация, зарождение идеи, поставленные цели, вехи пути и полученный опыт.

Начать надо с главного. Я гедонист. Нет, правда! В хорошем смысле слова: сценарий «обколоться анашой» и тупеть для меня не очень интересен. Просто я думаю, что все в жизни должно быть классно и интересно. А если нет — сделай так чтобы было.
Этот текст я начал писать в ночном тайском автобусе, следующем с острова Пхукет в Бангкок. Одно из ребер графа Москва-Бангкок-Хошимин-Муине-Паттая-Пхукет-Панган-Самуи-Бангкок-Бали-Москва, растянутого во времени на 5 месяцев.



Одно важное замечание: я не сбегал, не валил, не заводил трактор.
Просто однажды осознал, что радость жизни теперь можно черпать большей ложкой, и эпоха офиса может быть сменена на хайлевел фриланс.
Что такое хайлевел фриланс? Это когда работаешь за нормальные 20-30 баксов в час; не общаешься с заказчиками-гопниками; не кидаешь, не ждешь кидалова; работаешь с полной отдачей меньше 40 часов в неделю (кто работает в офисе реальные 8 часов и не сгорает через полгода?); контрибьютишь в open-source проекты по мере надобности и заводишь свои… потому что хочется это делать!

Приветствую, хаброжители!
В этой статье я хочу поделиться опытом развертывания кластера Master-slave на СУБД PostgreSQL. Отказоустойчивость достигается с помощью возможностей pgpool-II (failover, online recovery).
pgpool — это прекрасное средство для масштабирования и распределения нагрузки между серверами и, думаю, немногие знают о возможностях автоматического создания failover на ведомом сервере при отказе ведущего и как добавить новые мощности в уже работающий кластер без отключения всего кластера.

Всем привет! Продолжаем настраивать Windows Azure Recovery Services. В прошлый раз мы остановились на том, что загрузили необходимые сертификаты для работы с сервисом. Давайте же теперь наконец настроим Windows Azure Backup Agent для выполнения процесса бэкапирования.

Регистрация нового сервера

Теперь, когда хранилище бэкапов создано, мы создали и импортировали нужные сертификаты на Windows Azure Management Portal и на машины под управлением Windows Server, все что нам осталось – это установить на этих машинах Windows Azure Backup Agent и соответствующим образом его настроить.

Откройте Windows Azure Management Portal и перейдите в раздел Recovery Services. После этого выберите созданное хранилище бэкапов и перейдите на вкладку “Dashboard”.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Эта статья не для матёрых укротителей Python’а, для которых распутать этот клубок змей — детская забава, а скорее поверхностный обзор многопоточных возможностей для недавно подсевших на питон.

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

Данная статья предназначена для тех, кто использует или планирует начать использовать систему управления конфигурацией Opscode Chef.

Основная задача внедрения любой системы управления конфигурацией, будь то Chef, Puppet или что-то еще, — повторяемо воспроизводить и обновлять окружение всех сред, использующихся при разработке ПО (dev, CI, QA, stage, production). Отсюда следует, что само описание конфигурации необходимо однозначно хранить и обновлять. К сожалению, возможности по версионированию, которые есть в Chef, достаточно ограничены. Поэтому в связке с Chef в последнее время стали активно использовать Librarian. Но перед тем, как рассказать о нем, поговорим немного о кукбуках.

Нам понадобится всего лишь несколько минут для того что бы поднять распределенную файловую систему Ceph FS

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

Автор: Олег Гельбух

Прошлой осенью в блоге команды SwiftStack появился интересный обзор их подхода к созданию мультирегиональных кластеров Объектного хранилища OpenStack (кодовое название проекта — Swift). Этот подход хорошо сочетается со схемой географически распределенного кластера Swift с сокращенным числом реплик (3+1 вместо 3+3, например), над которой мы совместно работали с компанией Webex примерно в это же время. Я хотел бы кратко описать наш подход и остановиться на плане внедрения и предлагаемых изменениях кода Swift.

Текущее состояние OpenStack Swift

Я хотел бы начать с краткого обзора текущих алгоритмов Swift, чтобы затем пояснить, что именно требуется сделать, чтобы создать кластер из нескольких географически разделенных регионов.

А так же советы «Бывалого» в записи вебинара.


На этот раз на глубоком техническом уровне дан обзор по следующим темам:

• Что такое Hyper-V
• Версии Windows Server 2012 Hyper-V
• Аппаратные требования к Windows Server 2012 Hyper-V
• Динамическое выделение памяти
• Новый формат VHDX файлов, поддержка Native 4K Drives и дисков до 64Tb
• Возможности SMBv3
• Установка Hyper-V
• Миграция на Hyper-V и её сценарии
• Сервисы интеграции
• Модель безопасности Hyper-V
• Сетевые возможности Windows Server 2012 Hyper-V
• Виртуальные Fibre Channel
• Что такое Live Migration
• Высокодоступные кластеры Windows Server 2012 Hyper-V
• Live merge of snapshots
• Аварийное восстановление и Hyper-V Replica
• Азы управления при помощи System Center
• Hyper-V на клиентских ОС и их ограничения
• И многое другое...

В первой части статьи я делала общий обзор продукта Cisco Nexus 1000v и разворачивала апплаинс (VSM).
Во этой части я покажу, как можно настроить VSM и установить VEM — чтобы полностью подготовить Cisco Nexus 1000v для работы в vSphere.

Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100;

и скорость запросов на динамику (fastcgi_pass на php-fpm)

limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s;
limit_req zone=dynamic burst=10 nodelay;

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

Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго.

Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash.

Почти всё хорошо стало, но есть неприятные моменты:
— парсинг/сортировка логов тоже приличное (процессорное) время отнимает
— сервер тупит, если началась новая волна между соседними разборками (логов)

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой

error_page 503 =429 @blacklist;

И соответствующий именованный location

location @blacklist {
    fastcgi_pass    localhost:1234;
    fastcgi_param   SCRIPT_FILENAME    /data/web/cgi/blacklist.sh;
    include         fastcgi_params;
}

Дальше интересней.
Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт

В прошлый раз я описал концепцию и общую архитектуру Hyper-V Network Virtualization (NV) – технологии Windows Server 2012, обеспечивающей виртуализацию на уровне сетевого сегмента. Сегодня речь пойдет о настройке этой технологии с помощью PowerShell и System Center 2012 SP1 Virtual Machine Manager (VMM).

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

После очередного обновления centos, мы обнаружили, что разработчик pacemaker перестал поддерживать репозиторий для данной ОС, а в официальных репозиториях была сборка, подразумевающая совершенно другую конфигурацию (cman вместо corosync). Переконфигурировать pacemaker желания уже не было, и мы стали искать другое решение. На каком-то из англоязычных форумов, я прочел про Red Hat Cluster Suite, мы решили его попробовать.

Общая информация

RHCS состоит из нескольких основных компонентов:

• cman — отвечает за кластеризацию, взаимодействие между нодами, кворум. По сути, он и собирает кластер.
• rgmanager — менеджер ресурсов кластера, занимается добавлением, мониторингом, управлением групп ресурсов кластера.
• ricci — демон для удаленного управления кластером
• luci — красивый веб интерфейс, который подключается к ricci на всех нодах и предоставляет централизованное управление через веб-интерфейс.

Как и в heartbeat и pacemaker, ресурсы кластера управляются стандартизированными скриптами (resource agents, RA). Кардинальное отличие от pacemaker состоит в том, что redhat не подразумевает добавления пользовательских кастомных RA в систему. Но это с лихвой компенсируется тем, что есть универсальный resource agent для добавления обычных init скриптов, он называется script.

Управление ресурсами идет только на уровне групп сервисов. Сам по себе ресурс невозможно включить или выключить. Для распределения ресурсов по нодам и приоритезации запуска на определенных нодах используются failover domains, домен представляет собой правила запуска групп ресурсов на определенных нодах, приоритезацию и failback. Одну группу ресурсов можно привязать к одному домену.

Рассматриваем расширение возможностей System Center Configuration Manager (продукт для управления ИТ-инфраструктурой) при загрузке пользовательских ПК по сети используя PXE. Создаем загрузочное меню на основе PXELinux с функционалом System Center и добавляем возможности антивирусной проверки, образы диагностики и восстановления. В конце статьи касаемся особенностей работы System Center 2012 Configuration Manager совместно с Windows Deployment Services (WDS) при загрузке через PXE.

Все действия производим на тестовой среде, в которой уже есть установленный System Center 2012 Configuration Manager SP1, контроллер домена и некоторое количество тестовых машин. Предполагается, что в SCCM уже используется развертывание по сети используя PXE.