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

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

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

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



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

Этом цикле статей «Идеальный 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.

«Для чего в команде ping используются опции Loose, Strict, Record, Timestamp и Verbose?» — такой вопрос мне недавно встретился в вендорном экзамене. Они позволяют влиять на маршрутизацию ICMP пакетов и собирать информацию о транзитных L3-устройствах. Но занимаясь сетевыми технологиями уже достаточно давно, я почти никогда их не использовал.

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

Диагностику многих проблем на маршрутизаторе Cisco с операционной системой IOS XE можно начать с Packet Trace. Это трассировка обработки пакета внутри маршрутизатора, появившаяся не так давно. Ранее такой функционала был доступен только на межсетевых экранах ASA. Кто использовал packet-tracer на ASA, согласится – очень удобный инструмент. Теперь его аналог появился и на современных маршрутизаторах (ISR 4000, ASR, CSR).

Заметку я построю на живых примерах. Так проще получить представление о IOS-XE Packet Trace. Детали всегда можно найти на сайте вендора. Жаль, что там пока не много информации на этот счёт. По ходу нашего погружения вы поймёте, о чём я.

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


«Два типа людей в эксплуатации: кто уже сломал production, кто ещё только собирается это сделать»

Опубликованная 10 дней назад заметка собрала более 23 тысяч положительных голосов на Reddit и разошлась по другим специализированным ресурсам вроде The New Stack. Суть истории такова:

Помните недавний баг EFI на Samsung 530U3C, который приводил к тому, что ноутбук больше не работал после единоразовой загрузки ubuntu?

Встречайте EFI на Lenovo G580!

Итак, в канун нового года и праздничных распродаж, Adiost купил Lenovo G580 с FreeDOS, снес его и установил Ubuntu. Через какое-то время захотел установить-посмотреть Windows 8. В ходе этого обнаружил, что не может зайти в настройки EFI нажатием кнопки F2: просто-напросто ничего не происходило и начинала грузиться ОС. Плюнув на это, установил Windows 8, и начал чинить.

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

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

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

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

Начнем с названия. Я очень часто вижу что тремя буквами А-К-Б называют все что можно зарядить, абсолютно любой аккумулятор. Особенно тремя буквами люди любят называть аккумуляторы типа Li-ion. На самом-же деле АКБ аббревиатура от Аккумуляторная Кислотная Батарея. Под ними подразумевается лишь один тип аккумулятора — свинцовый кислотный. С современной точки зрения это название вызывает некоторый когнитивный диссонанс т.к. на данный момент значение слова «батарейка» т.е. гальванического элемента который зарядить нельзя перешло на слово «батарея». И получается как будто бы из-за слова «аккумуляторная» это аккумулятор который зарядить можно, а из-за слова «батарея» это как будто батарейка которую зарядить нельзя. В реальности-же батарея — просто цепь гальванических элементов и со словом «батарейка» имеет общий лишь корень.

Далее перейдем к некоторым мифам, а именно главный миф — АКБ для автомобиля имеет некие существенные отличия от АКБ для ИБП. И вот нельзя их применять и там и там.

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

Нужно больше золота! (С) WarCraft III

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

Да, SSD быстрее HDD. Да, после SATA II появился SATA III и всем стало веселее. Да, стали делать даже PCI-E накопители, но то протокол AHCI оставят, то цена устройства получается такая, что можно телевизор и PlayStation 4 купить…

Однако проблески надежды есть — OCZ RD400 — PCI-E или M.2 форм-фактор имеет, NVMe протокол поддерживает и стоит существенно дешевле, чем чугунный мост через Каспийское море. О нем (SSD от OCZ) и потолкуем под катом.

В нашей предыдущей статье о маршрутизаторе в виртуальном исполнении CSR 1000v от Cisco Systems мы постарались в максимально простой и краткой форме описать основные возможности этого замечательного продукта. Идеология подобных решений (и этого, в частности), на самом деле, очень проста и эффективна, т.к. виртуальное исполнение позволяет задействовать и максимально утилизировать имеющиеся вычислительные мощности. А, если учесть, что целевая область применения CSR – облачная инфраструктура, то ресурсов для его работы должно быть достаточно. При этом, повышается гибкость применения такого «устройства», т.к. его можно использовать на границах виртуальных сетей. Однако, в этой статье хотелось бы поговорить о том, как максимально повысить надёжность сети, минимизировать или даже свести к нулю время возможного простоя и не допустить появления единой точки отказа даже для небольшой группы виртуальных машин.

В октябре 2008 года Microsoft выпустила игру Fable 2 студии Lionhead. Она имела коммерческий успех и была хорошо принята критиками. На вечеринке в честь выпуска игры эмоциональный Питер Молиньё (Peter Molyneux) поделился хвалебными отзывами и поблагодарил свою уставшую команду разработчиков, в течение четырёх лет вкладывавшую все свои силы в игру. Позже Fable 2 выиграла BAFTA и стала самой продаваемой RPG для Xbox 360. Lionhead была на вершине мира.


Семь с половиной лет спустя сотню сотрудников Lionhead созвали на совещание в кафе компании. На ней Ханно Лемке (Hanno Lemke), генеральный менеджер Microsoft Studios Europe, объявил, что выпуск Fable Legends отменяется и Lionhead будет закрыта. Знаменитая студия, которую Питер Молиньё создал почти 20 лет назад, умерла.

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

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

Скажу сразу, что в сети очень много восторженных отзывов о том, как кому-то помогло длительное голодание (1, 2, 3). Отрицательных же (или хотя бы нейтральных) в разы меньше. Думаю, тут дело не только в мега-полезности голодания, но и в reporting bias — те, кому от голодания стало хуже, не особо горят желанием делиться опытом: ведь мало того, что неприятно рассказывать о своих неудачах, так еще и есть риск оскорбить религиозные чувства адептов голодания, которые расскажут, что ты всё делал неправильно, и вообще врёшь.

Наиболее взвешенная, на мой взгляд, научная статья по проблематике голодания была написана ещё в 1982 году. В её абстракте чётко изложены основные пункты, некоторые из которых я заметил и на себе:

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

Система построена на базе стека EHK (Elasticsearch/Heka/Kibana), с прицелом на работу практически в реальном времени. Особый упор сделаю на тонкие места и нюансы обработки миллиардов строк текста в сутки.

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

Довольно часто при оформлении сертификатов ключей электронной подписи можно наблюдать навязчивый пиар токенов с неизвлекаемым ключом. Продавцы из удостоверяющих центров уверяют, что, купив у них СКЗИ КриптоПРО CSP и токен с неизвлекаемым ключом (Рутокен ЭЦП или JaCarta ГОСТ), мы получим сертифицированные СКЗИ, обеспечивающие 100%-ную защиту от кражи ключей с токена. Но так ли это на самом деле? Для ответа на этот вопрос проведем простой эксперимент…

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

По американской статистике, 10% населения США в возрасте 12 лет и старше страдают от той или иной формы зависимости — в официальной терминологии это называется substance use disorder (SUD) (зависимость). Вероятно, в РФ этот показатель гораздо выше. По оценке РБК, здесь 10% населения принимают суррогатные напитки (медицинские лосьоны, «боярышник», омыватели стекла, паленка и др.), а легальный алкоголь употребляют многократно большее количество людей.

В последние годы люди стали проводить огромное количество времени в социальных сетях, где общаются, обмениваются мыслями и т. д. Это огромный объём информации, достаточный для системы машинного обучения. И зависимых людей в социальных сетях тоже очень много. Благодаря достижениям учёных стало возможным автоматически выявлять наркоманов, алкоголиков и курильщиков табака по их лексике и культурным интересам (музыка, фильмы).

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

Посещать собственный сайт в анонимном режиме

«Интересно, как выглядит мой сайт, когда я анонимный?» ^[1]

Лучше избегать посещения персональных сайтов, к которым прикреплены реальные имена или псевдонимы, особенно если к ним когда-либо подключались не через Tor / с реальным IP-адресом. Вероятно, очень немногие люди посещают ваш личный сайт через Tor. Это значит, что пользователь может быть единственным уникальным клиентом Tor, который сделает это.

Такое поведение ведёт к утечке анонимности, поскольку после посещения веб-сайта вся схема Tor становится «грязной». Если сайт малопопулярен и не получает много трафика, то выходные узлы Tor могут быть почти уверены, что посетитель этого сайта — владелец сайта. С этого момента разумно предположить, что последующие соединения с этого выходного узла Tor тоже идут с компьютера этого пользователя.

Источник: ^[2]

В первый день лета мы начинаем новую серию наших бесплатных вебинаров. В июне и июле предлагаем вам подробный обзор нескольких технологий и решений: гиперконвергенции (в том числе новой платформы HPE SimpliVity 380), инфраструктурных компонентов ЦОД, обновлений в нашем портфеле СХД, энергонезависимой памяти (NVMe), а также сетевых решений HPE Aruba. Регистрация на вебинары – под катом.