Есть два основных документа, которые чаще всего упоминаются при обсуждении стандартов центров обработки данных: это стандарт TIA 942 и классификация по уровням от Uptime Institute. Оба этих документа регламентируют уровни (Tier), что часто приводит к путанице: например, Tier III по TIA 942 и Tier III по Uptime Institute — это две большие разницы.

TIA vs Uptime

TIA 942 — Telecommunications Industry Association — Telecommunications Infrastructure Standard for Data Centers:

• Этот стандарт разработан ассоциацией телекоммуникационной промышленности США и, в первую очередь, касается вопросов организации структурированных кабельных систем в ЦОД, и в меньшей степени вопросов отказоустойчивости и других инженерных подсистем.
• Носит рекомендательный характер.
• Есть пошаговые инструкции и рекомендуемые схемы (помощь инженеру). «Делай как тут написано и получишь хороший результат».
• Соответствие стандарту заявляется владельцем объекта или исполнителем проекта (на уровне «Я делал как вы сказали, честное слово»).
• Обычно, на соответствие стандарту проверяется только проектная документация.
• Однажды реализованный объект не теряет уровень.

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

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

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

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

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

Привет habr! В данной заметке решил затронуть тему защиты от поддельных писем (Email spoofing, Forged email). Речь пойдёт о письмах, в которых так или иначе подделывается информация об отправителях. Получатель видит письмо, отправленное якобы доверенным лицом, но на самом деле, письмо отправлено злоумышленником.

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

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

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

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

• используется ли инструмент в инфраструктуре?
• если требуется что-то новое, то нельзя ли использовать то, что уже есть?
• насколько сильно обслуживание (обновление, перезапуск) сервиса будет отличаться от остальных сервисов?
• <...>

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

В нашей компании в качестве почтового сервера используется Zimbra Collaboration Server. И хотя при наборе адреса подходящие имена автоматически подставляются в адресное поле, однажды была поставлена задача сделать общую адресную книгу на базе GAL (global address list). Преимущество такой книги в том, что она всегда является актуальной, операции над акаунтами (удаление/добавление/редактирование) автоматически применяются к книге и отображаются у всех пользователей. В принципе задача не сложная, но как оказалось несколько заковыристая. Поэтому я опишу весь процесс, дабы помочь тем, кто столкнется с подобным. А также приведу примеры исправления возможных ошибок.

Описание касается Zimbra Coloboration Server версии 7.1.x установленной на Ubuntu server. Описывается настройка GAL в режиме «Внутренний». Использованы материалы из статьи GAL Sync Account, а также Zimbra forum

Это практическое пособие познакомит вас c Ansible. Вам понадобится виртуальная или реальная машина, которая будет выступать в роли узла для Ansible. Окружение для Vagrant идет в комплекте с этим пособием.

Ansible — это программное решение для удаленного управления конфигурациями. Оно позволяет настраивать удаленные машины. Главное его отличие от других подобных систем в том, что Ansible использует существующую инфраструктуру SSH, в то время как другие (chef, puppet, и пр.) требуют установки специального PKI-окружения.

Пособие покрывает такие темы:

1. Установка Ansible и Vagrant
2. Файл инвенторизации
3. Модули shell, copy, сбор фактов, переменные
4. Запуск на группу хостов
5. Плейбуки
6. Пример: поднимаем кластер, устанавливаем и настраиваем Apache и балансировщик нагрузок HAproxy
7. Обработка ошибок, откат
8. Шаблоны конфигурации
9. Роли

Ansible использует так называемый push mode: конфигурация «проталкивается» (push) с главной машины. Другие CM-системы обычно поступают наоборот – узлы «тянут» (pull) конфигурацию с главной машины.

Этот режим интересен потому что вам не нужно иметь публично доступную главную машину для удаленной настройки узлов; это узлы должны быть доступны (позже мы увидим, что скрытые узлы также могут получать конфигурацию).

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

Но случается и так, что мы беремся за работу над большими проектами. Под «большими» я понимаю композицию следующих факторов:

1. Более 50 проектов в solution’е. Назначение не всех из них вы знаете
2. Билд и выкладка длятся более 5 минут
3. Над кодом работают десятки или сотни человек в разных офисах (возможно и странах)
4. Существует четкое разделение труда и область ответственности каждой команды
5. Существуют строгие регламенты, стандарты оформления кода, прохождение ревью является обязательным критерием выполнения задачи
6. Учет рабочего времени производится позадачно, анализируются причины расхождения оценок и реальных трудозатрат

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

По адресу http://regulation.gov.ru/projects# доступен очередной проект закона о внесении очередных изменений в закона «Об информации, информационных технологиях и о защите информации». Точнее на данном портале сейчас выложено два таких проекта, но нас интересует проект закона от ФСТЭК РФ:



Что же предполагается изменить в методах защиты и кого касаются изменения?

Итак, в нашей прошлой статье мы рассмотрели как можно быстро и просто настроить среду для тестирования плейбуков и ролей Ansible. Это всё, конечно, очень хорошо и удобно, но почему бы нам не автоматизировать весь процесс внесения изменений в инфраструктуру от написания плейбука до внесения изменений на сервера?



Напомню несколько условий, при которых мы будем выполнять тестирование конфигураций:

1. Вся конфигурация хранится в git-репозитории;
2. Jenkins периодически опрашивает git-репозиторий с нашими ролями/плейбуками на предмет внесённых изменений;
3. При появлении изменений Jenkins запускает job с тестированием конфигурации. Тесты состоят из двух этапов:
3.1 Kitchen-CI берёт обновленный код из репозитория, запускает полностью свежий docker-контейнер, заливает в них обновлённые плейбуки из репозитория и запускает Ansible локально, в docker-контейнере;
3.2 Если первый этап прошёл успешно, в docker-контейнере запускается serverspec и проверяет, корректно ли встала новая конфигурация;
4. Если в Kitchen-CI все тесты прошли успешно, то Jenkins инициирует заливку новой конфигурации.

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

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

На сайте Poromenos' Stuff была
опубликована статья, в которой, в сжатой форме,
рассказывают об основах языка Python. Я предлагаю вам перевод этой статьи. Перевод не дословный. Я постарался подробнее объяснить некоторые моменты, которые могут быть непонятны.

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

Сетевые экраны D-link DFL-260E/860E/1660/2560/2560G NetDefend UTM обеспечивают защиту от вирусов, несанкционированного доступа и нежелательного контента, а также расширенные возможности управления, мониторинга и обслуживания сети предприятия.



Рассмотрим настройку этих сетевых экранов для работы с 3CX Phone System, находящейся в локальной сети за NAT. Настройка проводится по рекомендациям 3CX, в частности, публикуются неоходимые порты сервисов 3CX Phone System.

Недавно мы анонсировали дополнения линейки систем хранения данных начального уровня. Новости можно отнести к двум категориям:

• Во-первых, MSA. Главная новость — MSA 1040 теперь поддерживает твердотельные накопители. Команда MSA приложила немало усилий, чтобы сделать систему доступной.
  
  
• Далее — пополнение портфеля StoreEasy новым интересным продуктом StoreEasy 1650 Expanded. Его можно «расширять» дополнительным набором накопителей до общей емкости 224 ТБ (в шасси высотой 2U).

Это вкратце. А теперь расскажу подробнее.

Предыстория

В моей инфраструктуре в числе прочего работают три ESXi 5.5 сервера, подключенных к SAN HP MSA1000 (железяке уже в районе 10 лет) по оптике через свитч HP StorageWorks 2/8q, с использованием адаптеров QLogic QLA200. Разумеется, хранилище очень производительное, но также и очень скромное по объему. Так как виртуализация нынче — тренд, возникло непреодолимое желание получить реально большое хранилище, также подключенное по оптике с блочным доступом. Не буду обьяснять, почему именно блочным – холивары на эту тему начались еще на Ноевом Ковчеге, и это не относится к предмету данной статьи. Ну и как это всегда бывает, бюджет даже близко не позволяет прикупить некое брендовое решение, поэтому остается только становиться героем программы «Очумелые ручки».

Сегодня мы расскажем о коммутаторах Dell Networking MXL и PowerEdge M I/O Aggregator для установки в модульное шасси для блейд-серверов Dell PowerEdge M1000e, предназначенных для скоростной связи серверов как в пределах шасси, так и с соседними группами серверов, системами хранения данных и для подключения к ядру сети. Они поддерживают новейшие технологии для систем коммутации и благодаря этому могут быть использованы в составе сложных сетевых архитектур не только для увеличения скорости обмена данными и создания отказоустойчивых конфигураций, но и для конвергенции сетей передачи и хранения данных. Каждый из них обеспечивает производительность 1,28 Тбит/с в дуплексном режиме, поддерживает до 6 портов 40 Гбит/с и оснащен двумя слотами для установки модулей расширения, поддерживающих различные сетевые интерфейсы. Однако, как видно из названия, один из них относится к линейке сетевого оборудования Dell Networking, а другой к серверной Dell PowerEdge. Почему – разберемся при их изучении. Начнем с блейд-шасси.

12 марта мы провели очередной Zabbix Meetup, в этот раз приуроченный к выходу версии Zabbix 3.0. А сегодня мы спешим поделиться видео докладов.

1. «Zabbix 3.0, что дальше?» Алексей alexvl Владышев, Zabbix.

Вкратце:

1. cfpuppetserver — модуль автоматической настройки Puppet Server + PuppetDB + PostgreSQL + r10k + librarian-puppet
2. Краткое введение в Puppet
3. Описывается изначальное развёртывание с нуля

Привет, Хабр!

Я постараюсь докопаться до первоисточников IT-технологий, разобраться, как мыслили и какие концепции были в головах у первопроходцев, о чем они мечтали, каким видели мир будущего. Для чего задумывались «компьютер», «сеть», «гипертекст», «усилители интеллекта», «система коллективного решения задач», какой смысл они вкладывали в эти понятия, какими инструментами хотели добиться результата.

Надеюсь, что эти материалы послужат вдохновением для тех, кто задается вопросом, как перейти «от Нуля к Единице» (создать что-то, чего раньше и в помине не было). Хочется, чтобы IT и «программирование» перестали быть просто «кодингом ради бабла», и напомнить, что они задумывались как рычаг, чтобы изменить методы ведения войны образование, способ совместной деятельности, мышления и коммуникации, как попытка решить мировые проблемы и ответить на вызовы, вставшие перед человечеством. Как-то так.

Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker — «Understanding docker».

Что такое докер?

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