воскресенье, 28 августа 2016 г.

Как приручить трафик или traffic engineering в деталях

Как приручить трафик?

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

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

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

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

Существует по меньшей мере три типа автономных систем интернета - генераторы трафика (отношение исходящего трафика к входящему превышает 2), потребители трафика (отношение входящего трафика ко входящему превышает 2) и магистральные провайдеры ( отношение входящего ко входящему равно).

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

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

При использовании full bgp view, со стороны всех провайдеров мы получаем маршруты до всего интернета и мы должны выбрать лучший. Выбор лучшего осуществляется на основании ASPATH - числа автономных систем между нами и получателем трафика. Этот метод довольно эффективен и требует минимальный уровень контроля со стороны администратора.

Если же по тем или иным причинам у нас трафик распределился по провайдерам неравномерно, то мы должны прибегнуть к local preference , выбрать наиболее нагруженные направления, куда отправляется трафик и сделать путь до перегруженного провайдера хуже. Данный подход довольно эффективен. Как его альтернатива, может быть использовать policy based роутинг, чтобы в зависимости адреса от сети клиента в нашей сети направить его в тот или иной канал.

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

В случае потребителей трафика ситуация становится намного сложнее, так как арсенал средств балансировки входящего трафика все также основывается на методах выбора лучшего пути в bgp. А именно длине выше упомянутого ASPATH, а также на основании предпочтения к префиксам наименьшей длины. Поэтому все, что мы здесь можем - это использовать ASPATH prepend, чтобы сделать путь заведомо хуже через определенного провайдера. Либо же мы можем раздробить сети на более мелкие (тем самым увеличив full view, что тоже очень плохо) и увеличить поток трафика на выделенную сеть через определенного провайдера. Кроме этого, может быть использован параметр MED, чтобы выдать больший приоритет тому или иному каналу, но в этом случае нужно убедиться, принимает ли вышестоящий оператор этот параметр от вас, так как многие его обнуляют и не пропускают дальше.

Как вы можете заметить, если в случае генератора трафика мы имеем высоко автоматизированное или вовсе полностью автоматическое управление трафиком, то методы озвученные в разделе про потребителя трафика просто не будут действовать по той причине, что ожидается роутинг на основании логики алгоритма bgp, а мы её частично или даже вовсе отключили пытаясь добиться более надежной и стабильной работы своей автономной системы.

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

Безусловно, как генераторам, так и потребителям трафика (и даже магистральным операторам) стоит использовать системы управления трафиком , потому что они решительно улучшают качество интернет соединения, снижают необходимость постоянного контроля за bgp роутингом почти до нуля и что самое важное - позволяют решительно снизить затраты на каналы интернет путем их максимально эффективного и полного использования.

Дата написания: 26 ноября 2015 г., 12:06

О роли баз данных в надежности Интернета

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

Хочется начать сильно издали, от баз данных. Казалось бы, при чем здесь базы данных, когда мы говорим про Сети? Я попробую объяснить. Последние  5 лет наблюдается процесс экстенсивного укрупнения Интернет компаний.

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

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

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

К примерам таких сетей можно отнести - Facebook, Google, Youtube, Twitter (список совершенно не претендует на полноту). Это довольно разные по своей сути компании - социальные сети, хранилища контента, поисковые системы. Но их объединяет глобальный характер и популярность планетарного масштаба. Я специально не указал здесь сети, которые распространены в масштабах определенных стран, чтобы подчеркнуть именно глобальный масштаб оценки.

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

И тут мы подходим к самому Интересному, базам данных. Любой кто работал с базами данных MySQL, PostgreSQL, MSSQL и Oracle сталкивался с запросами, а как же обеспечить полное резервирование этих баз данных на случае сбоя. Кроме этого, почти всегда накладывается требование - сделать это на уровне базы данных, без внесения изменений на уровне бизнес-логики приложения. К сожалению, обобщенный ответ на этот вопрос почти всегда - "никак". Каждый из вариантов резервирования - master/master, master/single slave, master/multiple slaves является компромиссом и требует очень высокого уровня как квалификации архитектора подобного решения, так и предъявляет высокие требования к квалификации персонала и резко увеличивает необходимый для поддержки решения штат.

Безусловно, решения задачи резервирования баз данных существуют и для реляционных баз данных (SQL), так и для нереляционных, так называемых key-value или document-oriented баз данных, но каждый из них требует серьезных инвестиций и серьезных изменений в архитектуре приложения.

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

И здесь мы подходим к самому интересному моменту, что даже  крупные компании из перечисленных выше эту задачу не решают в полной мере. На 2014й год вся запись информации (например, публикация нового сообщения) на сайте Facebook безусловно уходила в США. В то время как графика и статический контент могли загружаться из Дата Центра в Швеции (Лулль). Казалось бы, ничего страшного, но в масштабе сети это очень неприятное явление. Так как нарушение связанности с сетями США в виду каких-либо проблем приведет к полной потере работоспособности сервиса и последующей потери его ценности для конечного пользователя.

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

Их нужно знать в лицо - наиболее устойчивые к сбоям протоколы.

Есть ли примеры реализации полностью устойчивых к нарушениям связанности протоколов и сервисов? Безусловно! Это наш любимый сервис - root DNS, который тоже в своем роде является очень большой географически распределенной сетью насчитывающей около тысячи узлов. Но в случае протокола DNS у нас нет необходимости менять значения для корневых зон, чаще всего меняются данные в листьях (записи в конкретной доменной зоне и записи для конкретного домена). И протокол DNS отлично справляется с обеспечением надежного хранения изменений. Несмотря на это, единая точка отказа все равно присутствует, как раз на ней хранятся данные о всех корневых серверах. Но, к счастью, в связи с довольно медленным процессом изменения данных в DNS (сравните с базой транзакций банка!) такой сбой пройдет скорее всего незамеченным даже если продлится несколько десятков часов.

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

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

Что в будущем?

Кроме этого, уже появилась реально работающая (и даже используемая в коммерческой услуге компанией Korea Telecom) реализация multipath tcp, которая позволяет добиться повышенного уровня надежности. Ранее данный функционал был реализован в протоколе sctp, но, к сожалению, он так и не обрел какой-либо серьезной популярности.

Также технологической проблемой на пути к построению реально надежных сервисом является отсутствие встроенной поддержки обеспечения высокой доступности как в протоколе HTTP, так и в протоколе HTTP2.

Выводы

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

Дата написания: 10 декабря 2015 г., 22:09.

четверг, 25 августа 2016 г.

вторник, 23 августа 2016 г.

Крайне неприятная фича Google Groups

Вот столкнулся с такой фишкой Google Groups, что все, кто подписывается на твою группу на самом деле не получают из нее писем, если не сделают это явно в настройках!

Несколько ласковых слов в эту сторону: https://productforums.google.com/forum/#!topic/apps/3OUlPmzKCi8

суббота, 9 июля 2016 г.

Как заставить Nginx использовать и SPDY и HTTP/2 одновременно?

Вот этим чудесным патчем от CloudFlare: https://blog.cloudflare.com/open-sourcing-our-nginx-http-2-spdy-code/

В чем суть? Суть в том, что в актуальном Nginx есть только HTTP/2, а у кучи пользователей старые браузеры и  имеется поддержка только SPDY. Патч от CF добавляет возможность выбора либо HTTP/2 либо SPDY и за счет этого серьезно увеличивает число пользователей, которые могут использовать все преимущества HTTP/2.

воскресенье, 26 июня 2016 г.

Оптимизация работы блога силами CloudFlare :)

Всем привет!

Провел большую работу по оптимизации работы блога путем подключения облачной защиты от DDoS, CDN и DNS от CloudFlare.

Что было сделано:

  • Перенос DNS на CloudFlare, он базируется на Anycast и работает очень быстро из любой точки планеты
  • Подключен протокол SSL и TLS для защиты трафика от прослушивания и подмены
  • Активирована поддержка HTTP/2 и SPDY.
  • Добавлена поддержка IPv6, теперь блог полностью доступен по данному протоколу!
  • Добавлены DNS серверы поддерживающие IPv6, теперь блог будет работать даже с IPv6-only машин.
  • Добавлены CloudFlare Page Rules для перенаправления с http на https версию, так как сам движок Google Blogger такое не умеет.

В FireFox могут наблюдаться небольшие уведомления по поводу небезопасности отдачи контента, но надеюсь, Google скоро это исправит. Также возникла проблема с Navbar (полоска в самом верху, где был поиск), ее также отрепортил в Google.

Не удалось добиться работы DNSSEC, так как регистратор моего домена REG.RU не поддерживает этот протокол несмотря на свои обещания еще из 2012го года его добавить.

Подумываю о переносе домена, к регистратору с данной функцией, чтобы обеспечить полную безопасность сайту :)

Работать сайт стал ощутимо быстрее, рекомендую всем :)

понедельник, 20 июня 2016 г.

Руководство по уходу за дисковой подсистемой выделенного сервера

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

Профилактических мероприятий тут два: RAID массивы (с резервированием - raid - 1, 5, 6 10, raid-0 и его производные защиты от потери данные не дает) и самостоятельное слежение за здоровьем дисков посредством различных средств.

Защита данных посредством RAID

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

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

Контроль состояния soft raid

Состояние soft-raid можно посмотреть командой:
cat /proc/mdstat
если все хорошо, то выдано там будет примерно следующее:
cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

md2 : active raid1 sda3[0] sdb3[1]
20972736 blocks [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
2104448 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
4200896 blocks [2/2] [UU]

Если же один из дисков откажет, то вместо [UU] будет [U_] либо [_U], это означает, что нужно написать в поддержку и указать на отказ одного из дисков и проблемы с RAID массивом. Вам должны будут заменить диск и, возможно, еще собрать массив.

Как же это автоматизировать? Не каждый же день дергать эту команду! Вообще, лучше каждый день. Потеря 1 секунды в сутки намного менее фатальна, чем отказ диска с информацией за годы. Конечно, есть способы автоматизации в виде mdadm monitor, но они упираются в электронную почту, которая никогда ни гарантией получения уведомления не отличалась. Так что если у Вас есть соответствующие знания, то пожалуйста, иначе - лучше руками.

Дает ли RAID гарантию от потери данных по механическим причинам?

Если же за RAID массивом следят и он всегда в состоянии ACTIVE, то я могу быть совершенно спокоен за данные? Да вот совершенно нет, кстати. Почему же? Во-первых, отказать могут сразу два диска (случай почти нереальный, но тем не менее согласно теории надежности имеющий место быть), может отказать электроника на одном из дисков, которая перестанет диагностировать ошибки чтения / записи (ввода-вывода) и на рабочий диск будет сдублирован мусор в итоге в лучшем случае немного повредится файловая система (обычно, лечится fsck), а в худшем будут потеряны данные. В своей практике я сталкивался с таким случаем и что-либо сделать в этом случае было нельзя.

Как защититься от форс-мажорных проблем c RAID

Для защиты от такого рода ошибок существует механизм само-тестирования массива. Когда система (по крону) раз в неделю запускает посекторное сравнение дисков массива и если находит отличия, сразу сообщает о них. Более подробно, об этом можно прочесть здесь: http://phpsuxx.blogspot.com/2010/04/warning-mismatchcnt-is-not-0-on-devmd2.html


Теперь немного о самих жестких дисках.

Мониторинг физического состояния жестких дисков
Проблемы с жестким диском можно определить двумя способами - напрямую (через систему самодиагностику жесткого диска именуемую SMART) и косвенно (ага, по потере данных, отказу сервера или же по ошибкам в dmesg).

S.M.A.R.T мониторинг жестких дисков

С мониторингом SMART посложнее, для его контроля используется пакет smartmontools (в CentOS его ставить: yum install -y smartmontools, в Debian: apt-get install -y smartmontools), в составе которого идет утилита smartctl, которая позволяет получить информацию от SMART подсистемы жестких дисков следующим образом:
smartctl --all /dev/sdX
Где sdX имя интересующего Вас жесткого диска (список имеющихся жестких дисков при использовании soft-raid можно посмотреть в команде cat /proc/mdstat). Тут в первую очередь стоит обращать внимание на параметр reallocated sectors, если он больше 20-30, то значит диск, скорее всего, скоро выйдет из строя и таже нужно написать в поддержку с просьбой его заменить.

Также в самом низу выдачи есть блоки "SMART Error Log Version: 1" - там могут быть большие записи (с кучей 16-ричных адресов), повествующие об отказе какой-либо из частей диска; если же диск в норме - там все должно быть пусто - "No Errors Logged". Кроме него, есть еще блок "SMART Self-test log structure revision number 1", в который пишутся результаты диагностических само-тестов диска. В нормальных условиях он выглядит так:
# 1  Short offline       Completed without error       00%     26274         -# 2  Short offline       Completed without error       00%     26248         -# 3  Short offline       Completed without error       00%     26226         -# 4  Short offline       Completed without error       00%     26200         -# 5  Short offline       Completed without error       00%     26178         -# 6  Short offline       Completed without error       00%     26151         -# 7  Short offline       Completed without error       00%     26127         -# 8  Extended offline    Completed without error       00%     26062         -

Но эти самые тесты нужно запускать либо вручную либо силами того же smartmontools'а (путем правки  /etc/smartd.conf).

Вручную запуск ускоренного теста осуществляется вот так:
smartctl -t short /dev/sdX
Запуск расширенного теста:
smartctl -t long /dev/sdX
Через некоторое время после запуска (несколько минут для короткого и до получаса-часа для длинного) поле "SMART Self-test log structure revision number 1" будет заполнено и будет добавлена информация о завершении теста.

Если какой-либо из тестов FAILED, то это повод идти к оператору Дата Центра и запрашивать замену сбойного диска.

Косвенный мониторинг состояния жесткого диска

Самый очевидный вариант - когда жесткий диск был выброшен из RAID массива по причине FAULTY (то есть возникла ошика ввода вывода и диск был отключен). Также косвенным показателем отказа дисков являются разнообразные ошибки (например I/O error) в выдаче команды dmesg.

Это также говорит о подтвержденном сбое с заданным жестким диском и должна быть осуществлена его замена.

Если с RAID и SMART все в порядке, могу ли я быть спокоен за данные?

И снова нет. Для полной защиты необходим последний штрих - бэкапы на внешнем носителе.

Бэкапы

Многие очень часто ошибаются, утверждая, что RAID дает гарантию от потери данных. От механических причин он, конечно же, спасет. А вот от деструктивных действий хакеров или ошибки администратора - навряд ли. Поэтому всегда крайне обязательно иметь на удаленном сервере полную актуальную копию всех важных данных.

Руководство новобранца по OpenVZ

Если Вам в руки неожиданно попадается OpenVZ ранее установленный кем-либо то этот гайд как раз для вас! Подразумевается, что OpenVZ у Вас стоит на базе CentOS 6. Про чудо-юду на базе CentOS 7 я писать отказываюсь наотрез :)

Итак, начнем. Что такое OpenVZ - это технология позволяющая запустить несколько копий операционной системы Linux в пределах одного физического сервера.

Итак, получить список всех имеющихся на сервере виртуальных окружений (также будет использоваться термин "контейнеры") можно командой: vzlist

Выдача которой имеет примерно такой вид:
      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
      1001        182 running   xx.xx.xx.xx  domain.ru
      1002          - stopped   xx.xx.xx.xx  second.domain.ru
Для идентификации контейнеров используется так называемый идентификатор контейнера - CTID. Его требуется использовать, если нужно что-либо сделать с контейнером.

Что с ним можно сделать?

Выключить (но если настроена его автозагрузка после нее он запуститься вновь):
vzctl stop 1001
Запустить:
vzctl start 1001
Отключить загрузку при запуске сервера (параметр --save необходим):
vzctl set 1001 --onboot no --save
Как искушенный системный администратор, явно вы будете использовать программы ps, lsof, top, netstat, ss и прочие на физическом сервере, где работает OpenVZ. Спешу Вас расстроить - эти утилиты не изолированы и будут показывать все процессы и все соединения принадлежащие всем виртуальным контейнерам на заданном сервере поэтому толку от этих программ не будет вовсе.

Итак, мы поняли как производить базовые операции с контейнерами.

Пройдемся по конфигам, стандартно конфигурации контейнеров хранятся по адресу /etc/vz/conf/CTID.conf, где CTID - идентификатор заданного контейнера. Конфиги довольно легки к пониманию и поддаются правке. После правки обычно требуется перезапуск: vzctl restart CTID.

Итак, но где же данные? Внимание! Сейчас они появятся. У OpenVZ используется две схемы размещения данных виртуального контейнера - ploop и simfs. Если у Вас ploop - это все усложняет и выходит за рамки статьи. В ploop данные хранятся в отдельном диске-образе и чтобы до них добраться нужно немного магии (магия простая - vzctl mount).

В случае же simfs данные доступны по адресу: /vz/private/CTID. Причем, вне зависимости от того, запущен контейнер или нет, все содержимое его жестких дисков находится там.

Теперь о том, как войти на контейнер OpenVZ. Тут два пути: обычный, силами ssh запущенного в виртуальном окружении и необычный - силами специальной команды.

Итак, необычный способ входа в OpenVZ контейнере следующий:
vzctl enter CTID
После этого Вам будет предоставлен доступ с root полномочиями в заднное виртуальное окружение так, как будто вы сидите напротив сервера и сидите с локальной консоли, разве что у Вас не будет запрошен никакой пароль. Выйти из этой консоли можно командой exit либо сочетание CTRL+D.

Теперь пару слов о багхантинге. Если Вы нашли эту статью, то явно с Вашим OpenVZ что-то не так!

Основные пути проверки проблем - это dmesg, в случае чего-то фатального о проблемах сообщит ядро. Второй частый историк проблем - исчерпание ресурсов внутри контейнера. Это можно зафиксировать стандартными утилитами free/top, но даже если они говорят, что все в порядке, Вам на помощь приходит файлик:  /proc/bc/CTID/resources, в котором можно найти вот такое содержимое:
            kmemsize                414620051            591908864  9223372036854775807  9223372036854775807                    0
            lockedpages                  4033                 7339              8388608              8388608                    0
            privvmpages               1809462              3191128  9223372036854775807  9223372036854775807                    0
            shmpages                    13839                15135  9223372036854775807  9223372036854775807                    0
            numproc                       179                  453  9223372036854775807  9223372036854775807                    0
            physpages                 6182653              6479824                    0              8388608                    0
            vmguarpages                     0                    0              8650752  9223372036854775807                    0
            oomguarpages              1344550              1532976              8388608  9223372036854775807                    0
            numtcpsock                    852                13014  9223372036854775807  9223372036854775807                    0
            numflock                        7                   43  9223372036854775807  9223372036854775807                    0
            numpty                          2                   31  9223372036854775807  9223372036854775807                    0
            numsiginfo                      0                  639  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                35976592            382477672  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                29720624            287987552  9223372036854775807  9223372036854775807                    0
            othersockbuf               210392              6495528  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0               661240  9223372036854775807  9223372036854775807                    0
            numothersock                  144                  957  9223372036854775807  9223372036854775807                    0
            dcachesize              309714841            310094288  9223372036854775807  9223372036854775807                    0
            numfile                      5474                11610  9223372036854775807  9223372036854775807                    0
            numiptent                      30                   30  9223372036854775807  9223372036854775807                    0
            swappages                    2372                 2967                    0               262144                    0
Обращайте внимание на последний столбец, если в нем не нули, значит контейнер упирается в заданный ресурс. И нужно разобраться - почему и решить проблему либо же увеличить лимит заданного ресурса путем правки конфигурации контейнера.

Ну вот, пожалуй, и все, что нужно знать про OpenVZ :)

воскресенье, 19 июня 2016 г.

Отключить IPv6 в Mac OS El Capitan

Из стандартного интерфейса не получится.

Используем магию:

networksetup -setv6off Wi-Fi
networksetup -setv6off Ethernet

Чтобы включить заново:
-setv6automatic
Причем, в интерфейсе будет корректно отображено "выкл" напротив IPv6.

Источник: https://louisville.edu/it/departments/communications/wireless/wireless-connection-problems-how-to-disable-ipv6 


суббота, 18 июня 2016 г.

Отсортировать размеры файлов в человеко-понятной форме

Очень часто встречаются данные вот в таком формате:
2,6G3,8G789M3,1G3,3G699M43M103M1,9G3,9G115M2,9G326M25M
И не менее часто нужно иметь возможность их отсортировать.

Как же это сделать?

На самом деле просто - использовать sort с ключем -h и на выходе получаем сортированные данные:
cat example.dat | sort -h

Выдача:
cat /tmp/example.dat |sort -h 25M43M103M115M326M699M789M1,9G2,6G2,9G3,1G3,3G3,8G3,9G
Но стоит отметить, что требуется довольно новый sort, в старых версиях этой фишки не было.  Например, в Убунту 16/04 такой вариант точно работать будет!

пятница, 17 июня 2016 г.

Конфигурирование сетевых интерфейсов в Ubuntu 16.04 удобно как никогда!

Удобное создание конфигов в отдельных файлах:
vim /etc/network/interfaces.d/eno1
Вот пример статической конфигурации:
auto eno1
iface eno1 inet static
address xxx
netmask 24
gateway yyyy
dns-nameservers  zz.zz.zz.zz aa.bb.bb.cc
Как же давно я этого ждал :)

Передернуть конфиг можно так:
sudo systemctl restart networking  

четверг, 16 июня 2016 г.

Продаются книги по ИТ не не только - только Питер

Всем привет!

Продаются следующие книжки, только Питер, географически - север синей ветки, метро пионерская:

  1. 100 Легендарных самолетов 250
  2. Cockpit confidential Patrick Smith 350
  3. Left behind Лахей и Дженкинс Жатва человеков: 150
  4. Sudents International гид по зарубежному образованию 200
  5. О Мексика - Люси Невилл: 250
  6. Веб аналитика Яковлев Довжиков: 150 р
  7. Ядро Линукс - Бювет Чезатти 850
  8. Ставь Цели - Ицхак Пинтосевич: 150 р
  9. Артур Хейли Отель 100р
  10. Книга начинающего инвестора Антон Монин 200
  11. Волчьи стаи - подводные асы гитлера - 200
  12. Научные теории за 30 секунд 150
  13. Мексика Потенциал Экономического развития Школяр: 300
  14. Оптимизация и продваижение Ашманов и Иванов: 350
  15. Контекстная реклама Seopult: 350 рублей
  16. Контекстная реклама Яковлев Довижиков: 200 рублей
  17. Конституция Эстонии: 100 рублей
  18. ПДД РФ + Экзамен ГИББ АБСД + Безопасность дорожного движения + Экзаменационные билеты АБ с комментариями: 500 рублей
ИТ:
  1. Junos for Dummies - Goralskiy 1000 р
  2. Linux азбука ядра Родригез и Фишер - 500
  3. Linux руководство программиста Фуско 350
  4. Linux программирование в примерах Роббинс 200
  5. STL спарвочное руководство Мюссер 1000
  6. Сеть Эндрю Блам 150
  7. Основы работы с Линукс Войтов - 200
  8. Тайм менеджмент для системных администраторов Томас Лимончелли 350

Если есть интерес, пишите конаткты в комментариях либо звоните: +79516808811.

воскресенье, 12 июня 2016 г.

пятница, 10 июня 2016 г.

11 reasons why you should avoid OpenVZ and Virtuozzo in any cases!


I want to share few words about me. I'm CTO of FastVPS Eesti OU with ~8 years of overall experience with containers and OpenVZ. I'm author of following tools for OpenVZ:

  1. Ploop userspace (user mode implementation of ploop filesystem)
  2. Fast incremental difference algorithm for ploop images.
  3. Author of script for TC based shaper for OpenVZ
And also, I'm author of 175 bug and feature requests at OpenVZ bug tracker.

From the operational side we have about few hundreds of physical servers with OpenVZ (VZ6 based) with pretty huge density and I'm trying to keep my hands dirty and dig into details of any issues.

What you should expect following technical issues when you are working with OpenVZ:

  1. Very often and repetitive kernel faults for different reasons even on top of top-notch hardware with ECC, redundant power and battery backed RAID's
  2. Huge disk space (up 30-40% in some cases) overuse if you decide to use ploop filesystem (that's true for VZ7 too). 
  3. Pretty often storage faults with complete data corruption if you are using ploop. You could read more details about it here.
  4. If you want to get security updates in timely manner you should not rely on OpenVZ team. You should use some external toolkit for applying patches to running kernel (Ksplice, Kpatch or Kernel Care).
  5. You should expect a lot of issues already fixed in recent kernels because OpenVZ project are relying on already outdated RHEL 6 or RHEL7 (based on top of 3.10 but current version is 4.6) kernel. You definitely know about huge backport work of Red Hat but these kernels are really outdated and you could get significant speedup with update to recent vanilla kernel (as Oracle or Ubuntu already doing). But please keep in mind if you are running OpenVZ (VZ7) you are running already outdated toolkit.
  6. You should expect significant changes without backward compatibility in next major release of OpenVZ (for more details please read more details about prlctl and vzctl). In some nice moment you should rewrite all your integration code from billing, configuration management and support control subsystems.
  7. Very poor QA and issues with pretty obvious things.
  8. Almost each upcoming systemd update in container may require new kernel from OpenVZ / Virtuozzo team. Actually, this updates could break your running kernel. 


If we are speaking about overall experience about project I could share my ten cents below:

  • You should not expect any openness in the decision making of OpenVZ project development. That's still true for day-to-day issues (bug priority) and for helicopter view (strategic planning). That's still commercial company and they will not discuss roadmaps with the community. If they decide to do something they will do it even if community hate their decisions. You should check "simfs deprecation" conversation in OpenVZ Users maillist for details.
  • You should have very experienced system administrator who should dig into details of each issue and system instability. 
We are discussed a lot of issues about OpenVZ project. But I want to highlight few issues abut container aware isolation technologies. We have two options if we want to isolate applications in containers:

  • OpenVZ (VZ6, VZ7)
  • Linux upstream containers (managed by LXC or Docker)

Unfortunately, Linux upstream containers could not run whole OS properly they are pretty insecure in compare with OpenVZ. But if you want to isolate your own applications I want to recommend to use Docker because they have a lot of benefits and haven't almost all OpenVZ issues.

But if you want to isolate whole operating systems (for making VPS service) I want to recommend KVM technology. But KVM has significant overhead in compare with containers! Actually, it's true only partially because Intel have been doing a lot of things for improving performance of hardware based isolation and recent CPU's (Xeon E3, E5) has lightning fast KVM implementation! But please be careful and do not use RHEL 7 (do you remember? It's already outdated and you could host more VM's per host with recent kernel!) and look at vanilla kernel, Oracle kernel or some other project which offer recent and stable kernel.

Finally, I really like container isolation and I will be happy when all mentioned issues will be fixed ;)

Thanks for attention!