kostich

порекомендуйте мне того кто мне оракел на фряшке будет готовить нормально.

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

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

ps. в России крайности сплошные, если кто еще не заметил... ортодоксальные юниксоиды кругом и рядом. у нас все ортодоксальное... у нас если требуют аптайт то требуют 100%, если требуют админа, то такого чтобы 365 дней в году был доступен... а если пьют водку, то пока всю из соседнего магазина не выпьют не разойдутся.

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

Ну персонала повидал пару ЖД вагонов и ортодоксов видел и тех и тех... и "cisco наше всио выкиньте телесин в помойку" тоже видали и т.д. и т.п. Если за стоимость обслуживания, то на фряхе получается как-то дешево. У начинающих админов косяков меньше... надо еще учитывать нашу консервативность, что конечно же от части косяков не может не ограждать.

Если по существу, то я и на фряху могу вылить вагон и телегу:

• нет сетевой файловой системы с dlm когда появился GEOM то были крики, что вот вот и оно появится, т.к. отладка очень удобна... ага... который год ждем... если кто сделаем комм. предложение, то готовы оплатить разработку новья или портинг существующего. кластер в load sharing хотим человеческий, а не этот запердос на nfs или HA уповающее на безглючность arp cache в 65тых.
• не ясно как сделать аля cpu bind... не ясно как его корректно сделать из kernel space
• в FreeBSD Kernel Developer's Manual были ошибки на предмет кодов возврата, что крови одно время очень сильно пило... доке типа доверять, но указатель перед записью надо десять раз проверять.
• не знаю как в линуксе, но работа на низком уровне с mbuf уже поперек глотки сидит
• pf без серьезного рашпиля откровенное гавно, т.к. менеджемент стейтов в критических ситуациях просто затыкается... rdr создает стейты даже в тех случаях когда они не нужны... у ipfw проблема с таблицами. ipf просто неюзабельно. но надо заметить что pf у нас держит в таблицах по несколько килосотен айпи в штатном режиме на хорошем трафе.
• с хитрым раутингом без применения pf, ipfw и т.д. никак нельзя... а это звиняюсь дополнительный вызов pfil на каждый пакет, что само собой стачивает стендовые pps-ы на тривиальных рутинговых задачах.
• нельзя сделать non local bind, что заставляет писать код тестилок под tun, а потом портить их под ng_
• при ошибках в расчетах loader tunables можно уронить сервак так что kvm без power switch ни разу не поможет... при тестинге этих tunables на аналогичном по параметрам сервере не факт что они встанут на продакшене с такими же параметрами но другой платформой.
• где оракл? где нормальная жаба?

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

лан... valgrind спасет мир!

ps. но когда его в нормально виде под фряху допортируют? или я давно его не ставил?

для нас это штатный...

ну надо заметить что хорошие TOE карточки и стоят как половина сервера

опять мимо... но уже не суть.

ну скажу что на какие-то машины у нас до 1mpps-а в штатном режиме приходится... конфиги оглашать не буду, т.к. очень долго к этому шли и потратили на это очень много денег. ларчик простой, но нервной системы откушал прилично.

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

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

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

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

ps. любому фряшнику очень полезно прочитать man tuning

kostich добавил 24.02.2008 в 14:12

а разделение на продакшен и тестовое только у нас одних что ли есть? мы спать хотим спокойно.

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

а от TSO какая-то реальная польза есть?

ну я верю что когда нибудь и native oracle под фрю будет...

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

отвечу абстрактно - в размере хороших по столичным меркам ЗП нескольким хорошим девелоперам.

Если бы всё решалось L2TP, то я бы про это не упоминал. Размер пакетика в 802.1q чуть больше и когда в качестве транспорта дают только ip по хорошему линку, а сетку нужно делать однородной, то приходится идти вот на такие ухищрения. В данном случае netgraph позволяет запихнуть всё as is в udp пакеты и выдуть из другого места.

в линуксе это называется bonding

$kernel_src/Documentation/networking/bonding.txt

почитал... в каких-то местах оно наверное даже удобнее.

kostich добавил 24.02.2008 в 14:19

UPD... ну представьте себе нашу специфику (см. в подписи)... сотни тысячь запросов в секунду... вот залез на две точки посмотреть стату - на одной 13406 активных сессий, на другой 28781... выходной однако... idle фактически... а в пиках мы раздаем до 100к ответов в секунду... на новой поделке, HTTP сервере со своим стеком, мы смогли выдать какую-то фантастическую цифру, но встал вопрос за правильность тестилки... скоро будет очередная стойка с пачкой серверов и там может быть что-то дотестим более правильно.

В ближайших планах параллельно построить CDN на 100Тб в мультихоумед AS с десятью точками по 1gb/s каждая. Как раз для тех кому нужно что-то раздавать в больших количествах большому количеству народа. И строить это будем на фряхе, т.к. все с ней в этом плане хорошо.

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

Вот во фряшке есть слегка кривоватенький accf_http, а в линуксе появился deffered accept... про хронологию появления молчу, кажется она примерно такая же как и у kqueue и epoll, что наводит на мысль тупого передиралова... но в этом ничего плохого нет. Если рассмотреть принципы работы линуксового TCP_DEFER_ACCEPT и фряшного accf_http (или accf_data) то мы видем большую разницу. Во фряшке есть механизм позволяющий принимать HTTP запрос еще до момента срабатывания accept, а после усовершенствования модуля (это еще ряд полезных патчей) этот запрос можно проверять на валидность и многое другое сразу в kernel space. Надо заметить, что даже без усовершенствования модуля это очень хорошо разгружает различные серверные архитектуры на медленных конектах без дополнительного ПО. Ну пропускает он POST на прямую и что? ну небольшой проход напильничком и мы получаем sysctl-ку, которая устанавливает максимальный размер запроса принимаемого в kernel space.

Опенсорц опенсорцом, а зарабатывать на чем-то надо. Мне без разницы в какую ОС вкладывать деньги, но при разработке и доработке FreeBSD их нужно меньше. Если мы говорим про HTTP high load, то однозначно FreeBSD. Как минимум только из-за одного accf_http.

Далее предлагаю обратить внимание на netgraph, которым большинство не умеет пользоваться и по сей день. Представьте себе, что штатными средствами решается гигантская масса сетевых решений. Нужен 802.1q тунельчик? г-но вопрос... скриптик из нескольких строчек и вот он бриджик упаковывающий данные из одной сетевухи и выкидывающий к примеру по UDP в другую на другой конец света. Можно много типовых полезностей перечислять в том числе и под телефонию. Многие фаны линукса про это просто не знают... а это появилось еще хрен знает когда. Когда-то мы думали ставить ли RADовскую железку для проброса портов из региона до столицы или попробовать фряшный netgraph.... да по сей день на фряхе работает кажется.

ng_fec использует кто? подскажите мне пожалуйста аналог ng_fec под линукс?

kostich добавил 24.02.2008 в 13:22

это не фриибсд-шники, а линуксоиды, которых заставили админить фрю.

спасибо

да мы сами большую часть секретов не скрываем... у нас есть громаднейшая куча фильтрующего оборудования на базе собственного ПО, которая располагается во множестве вкусных мест. наше адресное пространство анонсируется на уровне BGP фактически из каждой точки присутствия, что видно по трейсам и по as path на различных looking glass-ах. пришли мы к этой схеме не из-за того что не можем фильтровать всё в едином месте, а из-за желания сделать систему более надежной. в 2007 году из-за ддос-ов мы валялись суммарно не более суток, а вот из-за различных человеческих факторов со стороны сотрудников надежных ДЦ в разы больше. так же были случаи пропадания связи между местом из которого мы подавали прокси/туннель и местом присутствия клиента, иногда очень продолжительные. касаемо канального уровня на данный момент у нас уже под тысячу пиров, а к весне мы достигнем обещанных полторы-двух. в некоторых местах присутствия при выставлении нужного community на анонсируемую сеть трафик заворачивается через систему на базе cisco guard, но по известным причинам мы этим не пользуемся.

так же наш сервис используют ряд компаний для балансировки трафика между своими backend т.к. мы можем обеспечить более десяти фронтов по всему миру видимых из под одного IP адреса... и что самое ценное мы можем устанавливать такие фронты в свои стоечные емкости за умеренные деньги, в т.ч. и за трафик (от 5 до 50EUR за 1mbit CIR, в зависимости от точки присутствия).

ps. надеюсь скоро у нас будет свой сайт и мы на нем все красиво нарисуем...

kostich добавил 24.02.2008 в 10:15

что пошлют то и будет лететь: syn-ack flood, rst flood, fin flood и т.д...

ps. а еще есть специализированные атаки на syn cache или syn cookie... для некоторых ОС достаточно 10 мегабит хорошего спуфленого флуда и полный кирдык.

Да, кстати, ходят слухи, что load.cc активно рекомендует их сервис.

ps. кругом одни читоры...

Обратите внимание на динамику http://people.yandex-team.ru/~wawa/. IMHO как устаканится так и закомитят, т.к. лучшее враг хорошего. И рассматривать в контексте конкретной задачи надо. не кажется?