Есть несколько вопросов, которые встают перед фрилансерами, использующими кредитки или карты-рассрочки перед выездом за границу. Один из важнейших — это средство хранения денег и платежей. Карты русских банков по ряду причин становятся неудобны при длительном пребывании за границей — например, в случае утери, блокировки и необходимости восстановления. Или, например, при необходимости завести новый счёт в другой валюте — не полетишь же специально в Россию за этим? В последнее время добавились и политические риски. Но в итоге всё сводится к вопросу чисто логистическому: как получить банковскую карту, находясь за пределами родной страны.

Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Когда в Google Календаре появилась возможность получать бесплатные SMS уведомления, думаю все разработчики подумали о том, что это можно прикрутить к своим скриптам. Многие так и не нашли времени и сил этим заняться, поэтому предоставляю PHP скрипт для бесплатной отправки SMS себе, а для пущей пользы прикручу его к системе мониторинга Zabbix. Надеюсь после этих слов все системные администраторы подумали о том, как будет здорово получать SMS когда из сети выпадает сервер, кто-то наступает на сетевой провод, перезагружается роутер или повышается температура в серверной.

На любом околосетевом форуме легко найти с десяток веток о выборе оборудования для BGP-пиринга с возможностью «держать две, три, пять, двадцать пять фулвью». Большинство таких веток выливается в холивары на тему Cisco vs. Juniper или еще чего похуже. Офлайновое же их развитие нередко напоминает мультфильм о шести шапках из одной овичины. В общем, бывает смешно.

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

Периодически возникает задача миграции из одной почтовой системы в другую. В связи с тем, что часто эти системы не имеют штатного функционала сосуществования, их совместное использование может оказаться не самой простой задачей. Переход из одной системы в другую может выглядеть так — начиная с вечера пятницы системный администратор осуществляет настройку серверов, перенастраивает почтовые клиенты пользователей и переносит пользовательские данные. Несмотря на его старания, понедельник может оказаться очень «веселым» днем: или не все данные перенеслись, или какая-то старая система не может отправлять сообщения.
Мне хотелось бы рассказать про другой вариант совместного использования почтовых систем, благодаря которому можно добиться плавной миграции пользователей и сгладить возможные проблемы.
Для дальнейшего описания я буду использовать конкретные почтовые системы, но постараюсь сохранить применимость данного описания и для других систем. В качестве старой почтовой системы я буду использовать Microsoft Exchange 2013, а в качестве новой почтовой системы будет выступать Google Apps for Business. За рамками данной статьи находится процесс миграции пользовательских данных, так как он очень сильно зависит от текущей и будущей почтовых систем.

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

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

Концепция Cardberry

Концепция проекта заключается в том, чтобы перевести все дисконтные карты в digital и использовать их, имея при себе лишь смартфон и единственную электронную карту Cardberry.

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

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

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

Предисловие

В прошлом году компания, в которой я работаю, стала активно переходить на IP-телефонию. Для этих целей был использован дистрибутив FreePBX. Опыта работы с телефонией практически не было, поэтому проблем было много. Всего у нас используется 2 сервера FreePBX, примерно по 30 транков на каждом. Некоторые транки ведут себя не очень хорошо и порой теряют регистрацию. Поэтому возникла необходимость мониторить состояние регистрации, чтобы узнавать о неработающей телефонии раньше пользователей.
Для мониторинга IT-инфраструктуры мы уже давно используем Zabbix. Заводить элементы данных на каждый транк (т.е. около 60) — задача нудная, утомительная и неинтересная. Кроме того, надо постоянно следить за списком транков в мониторинге и актуализировать его. Поэтому, решено было использовать одну из самых интересных особенностей этой системы мониторинга — низкоуровневое обнаружение. Итак, что было сделано.

Продолжаю цикл коротких заметок по базовым, но весьма нужным хитростям для популярной АТС.

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

Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика, фактически стандарт как для образования, так и для траблшутинга.
Wireshark работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс на основе GTK+ и мощнейшую систему фильтров.
Кроссплатформенный, работает в таких ОС как Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Mac OS X, и, естественно, Windows. Распространяется под лицензией GNU GPL v2. Доступен бесплатно на сайте wireshark.org.
Установка в системе Windows тривиальна — next, next, next.
Самая свежая на момент написания статьи версия – 1.10.3, она и будет участвовать в обзоре.

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

Начинаем плаванье

Для начала захвата достаточно выбрать свой сетевой интерфейс и нажать Start.

Задача: Имеется роутер Cisco с кучей настроенных site-to-site IPsec-VPN-туннелей. Нужно настроить мониторинг загрузки туннелей в Zabbix 2.0.x
Предполагается, что SNMP на циске и в Zabbix'е уже настроен.

Основная проблема заключается в том, что нужные нам для мониторинга номера SNMP OIDs с отсчётами трафика формируются динамически. Мало того, списки этих номеров — также формируются динамически.

У меня на столе появился комплект беспроводного (Wi-Fi) оборудования корпоративного класса производства Juniper Networks. Данное решение позволяет организовывать централизованно управляемые сети глобального масштаба на базе специализированного ПО, широкой линейки контроллеров и точек доступа. Изначально разработанное компанией Trapeze (приобретенной Juniper в 2010 году) оборудование и софт продолжают активно развиваться; скоро выйдут 9я версия ПО, и виртуальный контроллер. С ростом популярности беспроводных технологий, наличием Wi-Fi модуля в каждом мобильном устройстве, тенденции к BYOD потребность в «нормальном» техническом решении возникает у все большего числа средних и крупных предприятий. Если вы стоите перед выбором поставщика оборудования, либо такую систему вам уже купили, мой пост (первый из трех по теме) поможет вам сориентироваться, понять что к чему, быстро внедрить железо в эксплуатацию.

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

Что хочет пользователь от ИТ отдела в первую очередь?

Добрых дел, уважаемые Хабравчане!

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

Читателю, которому требуется срочная помощь, а не рассказы о моих несчастьях, приведших к написанию данного топика, рекомендую пролистать до заголовка «Собственно сабж»

Где-то с полгода назад мне понадобилось поднять сервер для платежных терминалов с подключением к платежной системе по IPSec. Мой выбор пал на Debian Squeeze и KAME ipsec-tools, в простонародье racoon. Ох, и не знаю, почему моя душа прикипела к данному приложению. Сначала, поверхностно изучив теорию IPSec, я взялся за практику:

apt-get install racoon

В VMware vCloud Director, есть два типа внешних сетей — routed network и direct network.

При создании второго типа сети на VDS создается порт, к которому пробрасывается напрямую машина.
При создании второго типа сети для каждой организации создается виртуальный роутер — vShield Edge, который позволяет строить site-to-site VPN, делать публикации, пробрасывать порты на внутренние виртуальные машины, быть DHCP, NAT, балансировщиком нагрузки (при том что в 5.1 он может еще ставиться в HA режиме) и прочие полезные функции функции роутера.

Подробнее про него можно почитать тут.

Из интерфейса vCloud Director нельзя настроить VPN для подключения к нему с обычных ПК, но иногда это необходимо и чтобы не ставить внутри организации какой-нибудь сервер (будь то OpenVPN или MS TMG) можно настроить vShield так, что он будет служить сервером доступа.
Настроить может только администратор vSphere — прав у администратора организации в vCloud Director недостаточно. И я покажу, как можно это сделать.

В поисках решения для построения 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. Одну группу ресурсов можно привязать к одному домену.

Так случилось, что в короткие сроки появилась необходимость перевезти 70 человек с аналоговыми телефонами из одного бизнес центра в другой. Ситуация усугублялась тем, что в новом офисе у владельца не было аналоговых портов в АТС, а АТС в старом принадлежала телефонной компании. Пришлось в короткие сроки внедрять IP телефонию с переносом всех аналоговых городских линий на Asterisk. Поставка оборудования была назначена на день предшествующий дню переезда, что означало — времени на развертывание телефонии будет очень мало.

Что из этого вышло под катом.
Материала много, так что не пугайтесь.

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

Предстала на первый взгляд тривиальная задача: написать скрипт с различными опциями при запуске. Допустим нужно обработать всего две опции: name и dir. И задача действительно тривиальна при условии, что опции у нас короткие. Но если есть жгучее желание использовать длинные опции, то пиши пропало: getopts, который планировалось использовать изначально, в bash совсем на это не годится.

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

Топик очень хорош. Очень приятно почитать подобное с точки зрения разработчика.

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

За время работы у меня выработалось некое виденье идеального кластера для тяжеловесных проектов. Это:

— 2 WEB сервера

— 1 DB сервер

— 1 балансировщик нагрузки.

Совсем не ново, но соображения связаны именно с балансировщиком нагрузки