Category: it

Category was added automatically. Read all entries about "it".

трассировка в распределенных системах с маркировкой TCP соединений

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

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

вот не ждал от nginx такого

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

У apache httpd это дефолтное поведение: если соединений открыто больше, чем MaxClient, то остальные не акцептятся, а ждут.

У nginx при превышении worker_connections все новые соединения сбрасываются. Заставить их ждать никак нельзя. Разве что в коммерческой версии можно поставить лимит на число соединений с апстримом и если запросов оказалось больше, то принимать от клиента соединение, но запрос помещать в очередь.

Linux, UDP checksum, на заметку

При просмотре трафика через tcpdump -vvv, вижу, что он сообщает [bad udp cksum ...] о неправильной контрольной сумме любого UDP-пакета, проходящего через локальный интерфейс lo или, если используется виртуальная машина, через внешний виртуальный интерфейс. При этом поле контрольной суммы в пакете заполнено. Если пакет уходит через физический ethernet, то с суммой все в порядке и tcpdump пишет [udp sum ok].

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

По RFC, UDP checksum не обязательно вычислять вообще, и приложение может само решать, использовать ее или нет. Если ядро получило пакет без checksum, просто передает его приложению. Если checksum есть и неправильная, ядро должно отбросить пакет.

В линуксе есть socket option SO_NO_CHECK, которая отключает вычисление контрольной суммы при передаче. Ее использует, например, asterisk. Но сама опция в документации намерено скрыта:
-----------
    * From: "Andi Kleen" 
    * Date: Mon, 30 Aug 2010 00:26:51 +0200 (CEST)
> In the source of the socket.7 man page, there is a comment:
>
> [[
> .\" don't document it because it can do too much harm.
> .\".B SO_NO_CHECK
>
> ]]
...
On Linux UDP checksums are essentially free and there's no reason
to turn them off and it would disable another safety line.
That is why I didn't document the option.

-----------

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

Это приводит к редким граблям, когда dhclient отказывается принимать DHCP Reply, отправленный через обычный UDP-сокет и проходящий через xen vif, аргументируя это неправильной контрольной суммой. В линуксе dhclient работает как раз (7) packet. Чтобы клиент не страдал из-за неправильной суммы, dhcpd приходится самостоятельно собирать и отправлять IP-пакет, досчитывая контрольную сумму UDP в приложении.

(no subject)

Обычно несколько элементов (не идущих подряд, т.е. не slice) можно получить так:
$ perl -e '@a = (1, 2, 3); print @a[0, 2];'
13

$ ruby -e 'p [1, 2, 3][0,2]'
[1, 2]


А в питоне никак?
$ python
>>> a = [1, 2, 3]
>>> a[0,2]
TypeError: list indices must be integers, not tuple


UPD1: У меня чего это проблема возникла, пишу сейчас на питоне типовую задачу для перла - парсинг текстовых файлов и результатов вывода системных утилит. Там частая операция - разбить строку на поля (полей много) и вытащить несколько требуемых, что на перле выглядит так:
($device, $target) = (split())[8,10]

а на питоне проще, чем вводить промежуточную переменную, способа не нашел:
fields = line.split()
device, target = fields[8], fields[10]

.РФ

Оказывается, вопроса о введении кириллической зоны уже как-бы и нет. Форум ООН по делам Интернета, ICANN и КЦ решили, что она всем нужна и будет. А опрос, который инициировал сейчас КЦ, только о том, насколько нравится пользователям имя .РФ для этой зоны. Например, webnames проталкивает другую - .РУ.
Пресс-релиз от КЦ: Российское интернет-сообщество поддерживает домен .РФ

опрос КЦ про .РФ

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

Координационный Центр национального домена сети Интернет организует проведение ряда онлайн опросов в поддержку имени .РФ в качестве кириллического домена верхнего уровня.

Хотели бы Вы, чтобы России в дополнение к уже существующему домену RU был делегирован кириллический домен верхнего уровня "РФ"?

да
40(8.4%)
нет
438(91.6%)


Плюсов и минусов у введения .РФ достаточно много.

Самый большой плюс имеют регистраторы доменов *. Им это выгодно, т.к. большинство владельцев доменов в .RU будут вынуждены регистрировать параллельные домены в зоне .РФ. Еще это выгодно wannabe сквоттерам, т.к. открывается новое поле имен и они имеют шанс ухватить хорошие имена.

Это невыгодно действующим сквоттерам, т.к. обесценивает их имеющиеся домены. Если sunrise будет проведен без приоритета регистрации для уже существующих аналогов в .RU, то они могут остаться с доменов в .RU без аналога в .РФ. Если будет приоритет, им придется нести дополнительные траты на дублеров в .РФ.

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

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

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

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

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

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

Пока хватит, но список можно еще продолжать.

* Желание регистраторов получить новую зону хорошо иллюстрирует форма опроса на сайте Ру-Центра (доступна для клиентов Ру-Центра). Классический пример коммерческой пропаганды, паразитирующей на патриотизме. Цитата:
----------------------
Поддержи Россию, проголосуй за .РФ!

Уважаемые клиенты! Если вы хотите, чтобы Россия укрепила свои позиции в списке лидирующих интернет-держав, если вы за то, чтобы присутствие русского языка во Всемирной паутине расширялось, если вам удобнее набирать интернет-адреса на русском - скажите "ДА" кириллическому домену верхнего уровня .РФ.
----------------------

недоязык java

Ставим галочку: java хоть и в меньше мере, чем несколько лет назад, но все еще является недоязыком.

public class B extends A {
        B(String s) {
                String d = "B" + s;
                super(d);
        }
}

call to super must be first statement in constructor

И что же люди в таких случаях делают?
public class C extends A {
        C(String s) {
                super("C" + s);
        }
}


Или выносят реальный конструктор в какой-нибудь myConstructor(String s), который вызывают из конструктора и который при необходимости переопределяют и вызывают super.myConstructor в любом удобном месте. И судя по поиску, обсуждения нафига так это сделано ведутся уже 10 лет и заканчиваются аргументами, что это спасает от bad designed code. Ага, спасает.

tips: типографика и большие числа

Группы разрядов (тысячи) читабельней разделять не обычным пробелом, а сжатым или просто делать span-ом группы с отступом. Например, так: 32425243. Из побочных полезный эффектов - при вырезации html-кода получается монолитное число, да и браузеры понимают это одним словом и выделяют целиком.

трассировка выполнения программы

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

Когда символы есть, более-менее подоходит gdb, если поставить брейкпоинты на все функции и подавать скриптом cont до завершения:
$ gdb prog
> set pagination off
> br _init
> run
> rbr **
> cont
...
> cont

Когда символов нет, единственное, что напрашивается в том же gdb, это дизассемблировать либо весь код от _init до _fini и поставить брейкпоинты на все инструкции call, либо дизасемблировать итеративно - ставим br на _init, войдя в _init (a) дизассемблируем до ret, ставя br на все найденные до него call. Затем для всех найденных call смотрим их аргументы и повторяем шаг "a". Но все это как-то выглядит слишком сложно и у меня есть ощущение, что может быть можно как-то проще.

Скажу сразу, какие варианты пробовал и ничего путного не получил:
- Свой коротенький трейсер на ptrace и пошаговая трассировка - очень медленно, нереально, мне не хватило терпения дождаться когда завершится трассировка простого /bin/pwd
- Порт линуксовского callgrind скомпилировался, но при запуска падает в корку
- много слышал о порте сановского dtrace в freebsd, но работающего экземпляра не нашел

Больше ничего не нашел.

Расскажите, пожалуйста, какие инструменты и методы для трассировки выполнения программ вы используете или знаете?

Плата за повышенную отказоустойчивость

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

Какие меры по повышению отказоустойчивости принимали хостеры? Здесь я намеренно ограничиваюсь виртуальным, shared хостингом, т.к. для выделенных серверов и колокейшна задача повышения отказоустойчивости находится в зоне ответственности владельца или администратора сервера.

Первым был, пожалуй, Зенон, который в году так 97-м или 98-м внедривший схему работы "много фронтендов + много бэкендов". Далее Net.ru, где с 99-го года работала схема похожая на зеноновскую, но с разносом всей системы в несколько разных датацентров и рервированием серверов между площадками по N+K. Еще интересная схема была в 2000-2001 у одного небольшого хостера (к сожалению, уже давно закрывшегося, и жалко, что не могу вспомнить его имя) - две площадки в России и Штатах, на каждой NAS отдающий по NFS файловые системы серверам хостинга.
Похожая на Зеноновскую схема была сделана и в Мастерхосте плюс некоторые дополнения типа перекрестных NFS-линков, году этак в 2004 или 2003. У Каравана, кажется, было сделано тоже что-то подобное. Сейчас у многих крупных хостеров в той или иной степени используются различные кластероподобные технологии, которые кроме повышения отказоустойчивости дают еще и приятный бонус в виде снижения стоимости работ по обслуживанию системы.

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

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

Как эту задачу может решать хостер. Например, в 2000-м Net.Ru экспериментировал с синхронным кластером, узлы которого разнесены на разные площадки. В числе проблем, кроме огромной работы по доводке ПО, включая ОС, до приемлемого качества, были и вполне очевидные: большой трафик, который стоит больших денег и задержки на каналах, из-за которых работа самих серверов ужасно тормозлась. Тогда вторая проблема могла решиться прокладкой или арендой быстрых каналов, связывающих площадки, правда большие деньги превратились бы при этом в огромные. Сейчас и со скоростью, и с ценой (в Москве) дело обстоит намного лучше, но все-равно, для обычного хостинга это увеличило бы цену на порядок. У Net.Ru в итоге осталась асинхронная схема резервирования - по умолчанию с суточной периодичностью, для старших тарифов с более короткими. У асинхронного есть недостатки - у резерва нет данных, изменившихся после последней синхронной операции,
это, в свою очередь, делает бессмысленным включение резерва при коротких проблемах, например, если на площадке на 5 минут лег канал или из-за сбоя питания перезагрузился сервер.

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

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

Т.е. в итоге варианты с учетом цены сводятся к следующим:

1. то, что есть сейчас. дешевый хостинг $5 в месяц, со даунтаймами по несколько часов несколько раз в год, надежность - 99.5%.

2. то же самое, только владелец самостоятельно организовывает несколько зеркал, управляет своей зоной DNS, занимается синхронизацией данных между зеркалами. Стоит это около $30 в месяц,
плюс достаточно большие расходы на первоначальную установку и настройку всей системы (время = деньги). В реальности, если полагаться только на DNS, аптайм будет не существенно выше, ну 99.8% вместо 99.5%
А другие способы для дешевых аккаунтов хостеры просто не смогут предложить. Сравнивая с предыдущим вариантом, расходы за первый год будут больше примерно на $1000, и простой снизится с 44 часов до 17

3. Если это делает хостер по дешевой асинхронной схеме, как на примере выше. Цена будет примерно раза в два дороже первого варианта, около $10. Владельцу сайта никаких дополнительных настроек
делать не нужно. Аптайм - в среднем, 99.9% может быть и больше. Но эта схема, как и вариант 2,очень плохо приспособлена к кратковременным сбоям.

4. Та же асинхронная схема, но с небольшим периодом рассинхронизации, скажем, 5 минут ирегламентным временем переключения на резерв при отсутствии основного сервера больше 1 минуты.
При массовых решениях будет стоить уже около $50 в месяц и вполне приведет к желанным четырем девяткам 99.99%, менее 1 часа простоя в год.

5. Синхронная схема - цена от $100 до $200 (четыре незавичимые площадки). Аптайм для четырех вообще фантастический - девять девяток, 99.9999999%, 1 час в 100 000 лет. Но очень дорого.

6. На оборудовании хостера с разработчиками сайта он адаптируется под синхронно/асинхронную схему, учитывая особенности работы сайта. Здесь стоимость сложно формализовать. Стоимость технического обеспечения составила бы порядка $50, но стоимость работ по настройке может
сильно варьироваться - от нуля до $10K, выбор последнего случая можно оправдать только тем, что владельцу сайта все-таки не нужно будет решать вопрос администрирования и поддержки оборудования.

7. самостоятельная организацие отказоустойчивой системы на нескольких выделенных серверах, размещенных ра разных площадках. Стоимость аренды - от $100 до $1000 в месяц, стоимость разработки и запуска системы - от $50 для простых типовых решение типа apache/php/mysql до $10000 в более сложных случаях. Из плюсов - кол-во вычислительных ресурсов будет на порядок больше, т.к. не забывайте, что во всех предыдущих вариантах разговор идет об эквиваленте довольно таки дешевого тарифного плана, по которому хостер выделяет около 1% ресурсов сервера.

8. когда датацентр строится с приоритетом повышенной отказоустойчивости. Сейчас получается, даже наоборот: большинство датацентров даже жертвуют надежностью в пользу дешевизны. См. пост
Дмитрия Комиссарова http://komissarov.livejournal.com/328483.html про это. Здесь же просто замечу, что размещение в надежном датацентре стоило бы раз в три-пять дороже, чем средняя цена сейчас. Это повысило бы стоимость виртуального хостинга примерно вдвое-втрое, т.е. стоимость сайта из первого варианта здесь была бы около $15 в месяц при ориентировочном аптайме 99.9%

Если показать только цены, то получится (помним, что по функциям это некрупный сайт, небольшой интернет магазин, с посещаемостью, ну... порядка тысячи юзеров в сутки):
99.5%, 44 часа простоя в год - $5 в месяц
99.8%, 17 часов простоя в год - $30 в месяц и $500-$700 на старт
99.9%, 8 часов простоя в год - $10 в месяц, но плохо подходит для частых коротких сбоев
99.99%, 1 час простоя в год - $50 в месяц
99.9999999% - $200 в месяц

А что у нас в реальности:
вариант 1 возьмем как эталон, единицу, 100%
про успешную реализацию варианта 2 за все это время я слышал только несколько раз
вариант 3 - его предпочитают первому 2-3%
вариант 4 - 1-2%, уже как правило, организации или интернет-магазины
вариант 5 - во время дот-ком бума были такие в штатах, их уже не осталось. Обычно, предпочитают делать на выделенных серверах по варианту 7
вариант 6 - разовые случаи
вариант 7 - порядка 5% сайтов, размещенных на выделенных серверах, в той или иной степени делают такое резервирование.
вариант 8 - его в реальности нет. Так требует очень большие первоначальные вложения в строительство ДЦ. Тех нескольких процентов, которые бы могли стать клиентами такого ДЦ, слишком мало, чтобы оправдать его строительство. Но в будушем вполне может и появиться.

Получается, что тех, кто на shared-хостинге готов платить в несколько раз больше, чтобы увеличить аптайм с 99.5% до 99.9% - около 5% от числа всех. Тех, кто готов платить в 20 раз больше за снижение времени простоя с 8 часов в год до нескольких минут - их еще в несколько раз меньше, и они уже не входят в категорию обычных клиентов виртуального хостинга.

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

--------
просто линк слегка по теме http://sply.livejournal.com/100386.html