Рано или поздно настройкой резервного копирования рабочих файлов озадачивается любой уважающий себя современный IT специалист. После ряда опечаток/ошибок программистов нашлось время для этого и у меня.
Специфика веб-приложения такова, что рабочий каталог занимает более 50ГБ на жестких дисках, включая в себя около 900 тысяч мелких файлов (картинки, превьюшки, ...). Поэтому в лоб решить задачу с помощью tar и аналогов не вышло. Да и хотелось бы иметь некоторую вариативность хранимых данных, а в случае с полным бэкапом реализация требовала больших затрат на хранение по сути одинаковых данных с небольшими изменениями. Плюс неплохо было бы дублировать копии на удаленном сервере бэкапов для снижения риска потери критической информации в результате краха железа. После скрупулезного анализа поисковых выдач и отбрасывания заведомо неподходящих мне методов, остановился на паре вариантов, навязываемых чаще всего в комментариях к самописным shell-велосипедам энтузиастов.

Попытайтесь повторить это сами

Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Но этот показатель можно весьма ощутимо увеличить. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.

Минутка банальности.

yum -y install nginx

На всякий пожарный, создадим бэкап исходного конфига.

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
vim /etc/nginx/nginx.conf

А теперь можно и похимичить!

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

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

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

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

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



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

В нашей прошлой статье — «11 «рецептов приготовления» MySQL в Битрикс24» — мы, в основном, рассматривали архитектурные решения: стоит ли использовать облачные сервисы (типа Amazon RDS), какой форк MySQL выбрать и т.п.

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

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

А в конце статьи — сюрприз для самых терпеливых читателей. :)

Есть замечательная статья, в которой рассказывается, как это делается на Cisco. Но мы не хотим тратить $100500 на приобретение штампованных оттисков «Cisco Systems» на корпусе маршрутизатора.

Описание проблемы

Итак, суть проблемы: имеется два NAT через двух разных провайдеров, локальная сеть, в которой есть сервер и который должен быть публичным и доступным через оба NAT. У провайдеров разные приоритеты: сначала задействуется первый, потом второй.

Если пакет вошёл через первого провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера и уходит туда, откуда пришёл первый пакет. Хорошо.

Если пакет вошёл через второго провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера… а почему? Потому, что сначала в Linux происходит маршрутизация, а потом уже SNAT. Итак, при маршрутизации пакету назначается следующий узел — шлюз первого провайдера (по умолчанию). Потом происходит отслеживание соединения — conntrack замечает, что этот пакет является ответом на другой, и заменяет адрес отправителя адресом, который выдал нам второй провайдер. А потом пакет направляется через интерфейс первого провайдера на его шлюз. Как правило, провайдер блокирует пакеты, адресом отправителя которых указан адрес не из их подсети. Плохо.

Облака и виртуализация – термины уже привычные и плотно вошедшие в нашу жизнь. С ними же пришли и новые проблемы для IT. И одна из основных – как обеспечить в облаке (читайте кластер для виртуализации) адекватную производительность общего дискового хранилища?


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

Рухнула операционная система. Систему переустановили, но есть Задача: перенести учетные записи и почту из одной системы в другую. То, что для переноса «Личных папок» достаточно найти и скопировать файл Outlook.pst вместо вновь созданного (или подключить его вторым), знают многие. В «семёрке» он лежит кстати тут: С:\Users\%USERNAME%\AppData\Local\Microsoft\Outlook\Outlook.pst, где %USERNAME% — имя пользователя (или точнее – имя папки, в которой лежит профиль пользователя). Диск, кстати, у вас может быть тоже не C:\, если рухнувшая операционная система стояла на другом диске. А вот как перенести настройки «учётных записей»? Хорошо, если их было пару-тройку штук – можно легко и просто создать их заново. А если их было хотя бы десять?! Оказывается,

Добрый день, дорогой %username%!
Наверняка Вы уже слышали о Биткоинах. Возможно, Вам уже удалось ими попользоваться! Великолепно. Как насчет того, чтобы, не напрягаясь, начать майнить криптовалюту на 25 (50, 75, 100,…, 25n) Мегахешах в секунду? Как, у Вас уже есть суперкомпьютер для генерации блоков? Как насчет того, чтобы добавить 25n Мегахешей к Вашей вычислительной мощности прямо сейчас?

Есть отличный сервис Windows Azure от Microsoft. Вкратце, нам дают возможность пользоваться удаленной виртуальной машиной с 20 ядрами для различных серверных решений, вычислений, etc. Но для нас, любителей бесплатного, конечно, важен бесплатный триал на 3 месяца. Естественно, есть определенные ограничения для бесплатной версии, но нас они особо не затронут. Что нам нужно сделать (и что я пошагово опишу в этой статье) это:

1. Создать 3 виртуальные машины (8 + 8 + 4 ядер)
2. Подключиться к виртуальным машинам при помощи виртуального рабочего стола
3. Зарегистрироваться на публичном пуле (в статье я буду использовать Slush's Pool в качестве примера)
4. Установить и настроить нужный для майнинга софт
5. Запустить этот софт
6. Ждать
7. Получать биткоины

Всех заинтересовавшихся прошу под кат.

Update: добавил описание как майнить Litecoin на Windows Azure. Получается гораздо эффективнее майнинга Bitcoin.

Мне поступила задача организовать отказоустойчивость веб-приложения из двух серверов. Веб-приложение включает в себя статические файлы и данные в СУБД MySQL.
Основное требование заказчика — веб-приложение должно быть всегда доступно и в случае сбоя в течении 5 минут сбой должен быть восстановлен.
2 сервера, территориально разнесенные в разных ЦОДах, должны удовлетворить данное требование.

‎Первый раз про биткоины я услышал прочитав холодным зимним вечером эту статью. Как же я потом кусал локти, что тогда подумал что-то типа — «непонятная хрень», нажал ctrl-w и дальше уткнулся в хабр.

Через 2 месяца ко мне в гости в начале мая 2011 года приехал товарищ и сказал, что ему нужно съездить и купить видеокарты… На мой резонный вопрос «науя?» он ответил, что на видюхах будет генерить биткоины.

Во тогда я задумался… В изучении этой непонятной тогда субстанции из криптографии, экономики, алгоритмов и финансов я пропал почти на четверо суток. В голове не умещалось одно — как такое может быть? Где-то тут есть подвох? Ну это точно очередная пирамида…

Особенное подозрение вызывал тот факт, что создателя — некого Satoshi Nakamoto — никто никогда не видел, и личность эта скорее мифическая…

За это мы с друзьями прозвали их фантиками.

В 2009 году, на ежегодной научной конференции SIGMETRICS, группа исследователей, работавших в Университете Торонто с данными, собранными и предоставленными для изучения компанией Google, опубликовала крайне интересный документ "DRAM Errors in the Wild: A Large-Scale Field Study" посвященный статистике отказов в серверной оперативной памяти (DRAM). Хотя подобные исследования и проводились ранее (например исследование 2007 года, наблюдавшее парк в 300 компьютеров), это было первое исследование, охватившее такой значительный парк серверов, исчисляемый тысячами единиц, на протяжении свыше двух лет, и давшее столь всеобъемлющие статистические сведения.

Отмечу также, что та же группа исследователей, во главе с аспирантом, а ныне профессором Университета Торонто, Бианкой Шрёдер (Bianca Shroeder) ранее, в 2007 году публиковала не менее интересное исследование, посвященное статистике отказов жестких дисков в датацентрах Google (краткую популярную выжимку из работы Failure Trends in a Large Disk Drive Population (pdf 242 KB), если вам скучно читать весь отчет, можно найти здесь: http://blog.aboutnetapp.ru/archives/tag/google). Кроме того, их перу принадлежит еще несколько работ, в частности об влиянии температуры и охлаждении, и о статистике отказов в оперативной памяти, вызываемой, предположительно, космическими лучами высоких энергий. Ссылки на публикации можно найти на домашней странице Шрёдер, на сервере университета.

Всем привет!

Предлагаю сделать простую проверку безопасности на ваших серверах.

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

Замечу, что например апачевский юзер не должен иметь прав на изменение и удаление апачевских логов.

С Новым Годом!

В нашей компании возникла необходимость оповещения по SMS о задачах, поставленных в трекере Redmine, с приоритетом «Авария!». Очень удобно получать такие оповещения, когда требуется мгновенная реакция.

Совместно с командой разработчиков из secoint.ru мы разработали плагин redmine_status_notifier, о котором я и расскажу под катом.

Наступила неделя Большого Брата. +5 к паранойе.

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

Но, что делать, если нет;
1. прав админа на компьютере;
2. root-доступа на устройстве;
3. своего внешнего хостинга или денег на него;
4. знаний и умений по настройке всего этого;
5. банально, времени на все это;
…
WHATEVER?

Всем привет!

В одном из моих проектов используется нечто, немного похожее на частное облако. Это несколько серверов для хранения данных и несколько — бездисковых, отвечающих за виртуализацию. На днях я похоже что наконец поставил точку в вопросе выжимания максимальной производительности дисковой подсистемы данного решения. Это было довольно интересно и даже в некоторые моменты — довольно неожиданно. Поэтому и хочу поделиться своей историей с хабрасообществом, которая началась в далёком 2008м году, ещё до появления «Первого облачного провайдера России» и акции по рассылке бесплатных счётчиков воды.

Архитектура

Экспорт виртуальных жёстких дисков осуществляется через отдельную гигабитную сеть по протоколу AoE. Если коротко — это детище компании Coraid, которая предложила реализовать передачу ATA-команд по сети, напрямую. Спецификация протокола занимает всего десяток страниц! Главная особенность — это отсутствие TCP/IP. При передаче данных получается минимальный оверхед, но как плата за простоту — невозможность роутинга.

Почему именно такой выбор? Если опустить перепечатывание официальных источников — в т.ч. и банальный lowcost.

Соответственно, в хранилищах мы использовали обычные SATA-диски с 7200 rpm. Их недостаток известен всем — низкий IOPS.

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

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

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

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

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

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

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

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

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