NiTr0

http://abills.net.ua/forum/viewtopic.php?p=18748#p18748 в помощь. Гуй вокруг думаю сами осилите наваять. И не нужно привязываться к персонализации через анус чьего-то софта, + гуй можно и под корпоративный стиль сделать.

Насчет цены чипов можете узнать здесь http://local.com.ua/forum/topic/27532-%d1%80%d0%b5%d0%b0%d0%bd%d0%b8%d0%bc%d0%b0%d1%86%d0%b8%d1%8f-wi-fi/ (сам думаю там к планетам заказывать), насчет работы - если там TQFP, то в принципе перепайка особо много умения и сложной аппаратуры не потребует (сдуть/срезать старую микруху + запаять новую - дело получаса максимум), если BGA - тут уже сложнее, одной китайской воздушки маловато будет, + результат будет сильно зависеть и от оборудования, и от навыков мастера, джамшутинг "на авось" не проканает. + возможно придется менять трансформаторные сборки, если из-за разряда внутри него образовалось межвитковое/обрыв/КЗ между входом и выходом.

У нас пользуются заводские грозки, ценой что-то грн 28 если не ошибаюсь (не я закупками занимаюсь). Отличия: 1) Разрядники не на каждую пару, а один с "плюса" или "минуса" "мостиков" на землю. 2) Вместо супрессора - пара диодов в прямом направлении (вернее, пара 1N5408 и пара 1N4007, от средней точки соединения 4007 отходит на землю искровой промежуток в виде гребенки на печатной плате + неонка, в новых - вместо неонки разрядник).

По ПУЭ - можно, если в щиток приходят 3 фазы и 0. Хотя, если проводка гнилая и сделана стройбатом "на соплях", все же стоит поискать заземлитель понадежнее - к примеру, завести земляной провод в щитовую. В любом случае, грозозащита даже без заземления значительно уменьшает вероятность выгорания порта.

Planet GSW-2416SF ECOLAN Спасибо. Сроки доставки какие? И как вообще с доступностью их в перспективе?

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

VSC8558HJ (или VSC8558XHJ - последние менее предпочтительны т.к. бессвинец, паять на коленке труднее будет) - почем будут в кол-ве нескольких штук (ориентировочно 2-5шт)?

При теперишних ценах на оптику/свичи с SFP - имеет смысл дяже FTTB тянуть. Ну или хотя бы FTTD, с питанием окрестных свичей по PoE/по свободным жилам кабеля стабилизированной постоянкой 24В. У нас сейчас FTTD, но в некоторых районах уже предстоит переход на FTTB.

Чек по крону в помощь. Будет невосстановимый бэд - неисправный винт отвалится, и делов-то.

Отнюдь. Уже держал брасы обычных полновесных дистрах. Желания возвращаться к мастодонтам нет. Как-то с embedded легковесным дистром поспокойнее, да и работает намного шустрее. И апдейтится заметно проще... И еще меньше желания испытывать на себе свежие глюки closed-source дистра или подстраиваться под ограничения, заложенные его разработчиками. В кошерной иностранной фирме с локальным представительством однако 8-часовый рабочий день с довольно строгим графиком (ессно, не с 8 до 5, но обязан появиться до 10-11), отработать 8 часов с регламентированным перерывом на обед, а оставшееся время, которого практически не остается - тратить на личные проблемы. Хотя да, относительно спокойно и платят неплохо (хотя жилье будет съедать солидную часть з/п либо проезд в транспорте с работы/на работу будет занимать большую часть свободного времени). Менее кошерные фирмы - и платят хуже, и график строже, и регулярные завалы перед сдачей проектов. + везде строго ограничен "фронт работ" - а пилить неделя за неделей какой-то софт для бухов к примеру весьма скучно. + ко всему - как я говорил, з/п у меня достаточная для нормальной жизни. И опять же, особо больших проблем, требующих моего непосредственного участия в решении, от чего-то практически не возникает.

MCP68 вроде как должен поддерживать AHCI, который в свою очередь предусматривает hotplug Попробуйте на ходу у непользуемого винчестера отключить/подключить SATA шлейф и посмотрите что в dmesg будет.

При наличии большого кол-ва свободного времени - локализовать не проблема. Запустить бисекцию коммитов ядер между 2.6.32 и 2.6.35 (ориентировочно - порядка 20 итераций)... Но мне это потраченное время никто оплачивать не будет, и практического смысла с него ровным счетом 0. Ну узнаю, какой кусок кода неадекватно компилится gcc 3.3.3, а что дальше? Ой какие вы ужасы-то описали... Админ, от безделия, по мэйл-листам с лупой выискивает баги, чтобы было чем заняться в рабочее время - героически их устранять... Ну если голова и руки не заточены в правильном направлении ни у технического директора, ни у сисадмина - тогда да, приходится оплачивать работу тех, у кого руки и голова растут из нужного места. Хотя в этом случае возникает вопрос: а чем тогда упомянутые сотрудники занимаются? Не беспокойтесь, есть и комьюнити, и тестировщики, и программисты. И сами же клиенты с огромной радостью выступают в роли тестировщиков - стоит им только пообещать какую-то замануху как компенсацию возможных проблем со стабильностью (да хоть +50-100% полосы). Ессно - участие в тестировании добровольное. А результаты собссно налицо. В 4.0 ветку активно коммиттили 3 разработчика, цикл разработки от первой работоспособной альфа-сборки (которая, к слову, стабильно отработала несколько месяцев на одном из квартальных роутеров до его демонтажа в рамках реорганизации сегмента) до выхода стабильной версии - год +-месяц. Имеются, имеются, не беспокойтесь. Админом работаю потому, что 1) з/п хватает 2) гибкий график (необходимое свободное время обычно могу найти именно тогда, когда мне нужно, а не тогда, когда позволит работодатель) и 3) огромные возможности для дальнейшего самообучения, опять же в процессе работы. А если быть еще точнее, администрирование серверов - лишь одна из моих обязанностей. Среди многих других - начиная от адаптации/написания ПО под наши нужды, оканчивая техническими вопросами (в т.ч. выбором или разработкой источников питания под "нестандартные" техусловия).

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

Ну опять... Какие бинарники? Откуда вы бинарники-то взяли? Если вы генту ни разу не юзали и вообще в глаза не видели - да будет вам известно, что нету там бинарников. Вообще. Кроме нескольких больших пакетов, компиляция которых занимает много времени (типа опеноффиса), ну и пакета x86 библиотек для x86_64. Все остальное - собирается непосредственно из исходников установленным в системе компилятором. У вас плохо с пониманием английского? При компиляции ядра gcc 3.3.3 - wifi AP на ath5k не работает, возвращает абсолютно левый код ошибки, при компиляции того же ядра с тем же конфигом gcc 4.4.3 - вафля заводится адекватно. Да хотя бы тем, что при выявлении проблемы с чужим дистром остается рассчитывать только на техподдержку ихнюю. Которая, к слову, чешется весьма неспешно. Кстати, в свое время на CentOS/Fedora/RHEL месяца 2(!) не могли/не желали устранять проблему с KVM, приводящую к крашу linux виртуалок с ядрами 2.6.32 и старше. Багрепорты игнорились (CentOS) или закрывались как invalid (Fedora/RHEL). Сидел на старой версии KVM пока пофиксили. То, что вы не умеете "готовить" туннели - еще не значит, что они непригодны для пользования в ISP. "А мужики-то и не знают" (с) DOM есть и на SATA. И используются они как раз там, где нет набортных CF слотов. Хотя конечно можете лепить китайские переходники и считать это мегоэнтерпрайзом - дело ваше... Кстати куда вы будете пихать CF, когда IDE окончательно исчезнет с плат (а случится это года через 2-3 максимум)? Покупать китайские глюкавые SATA-CF адаптеры, и называть это тоже мегаэнтерпрайзом? А отличие в том, что DOM - какбэ модули, выпускаемые по industrial стандарту. А китайские адаптеры CF-IDE - ну аж никак не соответствуют industrial требованиям. Поскольку контроль качества при их производстве как таковой практически отсутствует - элементарно может обнаружиться даже непропай. О качестве CF слотов на них, механических свойствах припоя и о хим. составе "типа позолоты" их ламелей - вообще молчу. Для отключения в конфиге ядра ненужных модулей (да того же KVM и иже с ним, который и даром на роутере не нужен) - уже нужно иметь минимум 10 лет опыта работы программистом? смешно... Да, vyatta, в которой тянется громоздкий монструозный glibc - просто эталон минимизации При том, что дистр, собранный с uClibc, имеет для каждого процесса потребление памяти в 2-5 раз меньше (что весьма положительно сказывается на производительности - как из-за меньшего объема кода, так и из-за меньшего кол-ва cache miss).

Чукча не читатель, чукча писатель? Читаем внимательно мой каммент под номером 11. Сразу видно человека, генту в руках не щупавшего. Я беру ядро, скомпилированное и сконфигуренное лично мной, на моей рабочей системе. Оно с вафлей и 32бит юзерлевелом работает. Потом беру ядро, испеченное gcc 3.3.3 - оно с тем же юзерлевелом не работает. Потом меняю компилятор на 4.4.3 - и о чудо, с тем же самым конфигом вафля оживает! Но во всем конечно виноват не криво сгенеренный старым гнусом код, и ядреные девелоперы в связанном багрепорте тоже оказывается не правы были, советовав обновить gcc... однако А у нас есть. И не только у нас. А какие-либо аргументы, кроме ваших личных фантазий, будут? Ну в википедию хотя бы заглянули, или в прайс-листы на крайняк... Весьма удобная вещь. В отличие от CF, требующих китайские же переходники.

С заводом при заказе в 1-2 единицы - шутник однако Если что-то популярное - aliexpress или инет-магазины в помощь. Ну или ибэй. Растаможка до 200 евро - бесплатная. При сумме несколько выше, ессно, можно попросить отправителя указать меньшую сумму, но не факт что прокатит. Превышение суммы - +30% за растаможку к той стоимости, которую насчитают на таможне (она к слову можт и не совпадать с реальной - ессно, в большую сторону). Доставка - обычная china post/hongkong post идет недели 2, EMS - побыстрее и понадежнее. При больших заказах - имеет смысл обратиться к китайским опять же аудиторам, которые проведут аудит завода (или "завода"), и вышлют вам отчет. Потому как вполне можно найти "завод", который предложит весьма заманчивые цены - и после внезапно испарится с вашими деньгами без следа...

А вы? Я предпочитаю знать, что за софт крутится на моей железке, и иметь возможность покопаться в его коде при необходипости. А не надеяться на то, что в экспериментальную ветку девелоперы будут коммитить исключительно стабильные патчи. Дело в том, что я лично видел CF, умершую при использовании в обычном фотоаппарате. Где куда меньше циклов записи в единицу времени, чем в случае системного диска с логами/свопом/etc. Что именно? Вас смущает аптайм в полгода-год? Скриншоты выложить? Повторюсь: первый баг и второй. В обеих случаях единственное решение, предложенное девелоперами ядра - обновить GCC. Видать, тоже шаманы... Не единственный. Возможно, не самый лучший. Но от чего-то именно gcc традиционно пользуется при компиляции линукс-дистрибутивов (даже вашего дебиана), и от чего-то ключи компитятора в мейкфайлах линукс-специфичного софта опять же gcc-шные. И перелопачивать мейкфайлы всех пакетов ради получения нескольких % прироста скорости от использования "лучшего" компилятора у меня желания совершенно нет. Мне достаточно прироста от пользования uClibc. И? Сколько коммиттеров ядра работает в красной шапке? Тем не менее - федора от этого стабильнее не стала. Что, в принципе, и не удивительно для проекта, который самими разработчиками позиционируется отнюдь не как энтерпрайз, а как тестовую ветку для обкатки того, что войдет в энтерпрайз. Кстати, vyatta фришная тоже позиционируется именно так... С чего это оно проприетарное? Может, вы можете назвать организацию, требующую лицензионных отчислений за использование реализации RFC3576 в сторонних проектах? А может, он не пользуется в микротике, MPD5, chillispot'е, а теперь - и в accel-ppp? И какую же вы альтернативу RFC3576 предложите? Неужто скриптовые костыли к SNMP, ни с чем не совместимые? А может - коннект по ssh для каждого изменения настроек шейпера? Или изобретать велосипед, писать демон со своим протоколом вместо RFC3576? Вас удивляет, что полноценный роутер/брас влазит в 16МБ DOM? Или может, DOM имеют срок годности? Я к примеру не вижу причины, зачем мне выбрасывать устройство, если оно на 100% удовлетворяет предъявляемым к нему требованиям. Неужто только потому, что куплено давно?

У нас пару еще есть вроде. Самые первые DOM, купленные еще в 2004-м. Живы до сих пор, и будут жить думается еще не один год. Для vyatta имеется к примеру SDK? Туда можно добавить хоть что-то сверх того, что имеется? Да и фришная версия, как я понял - является тем же, что и Fedora по отношению к RHEL - глюкодромом для бета-тестирования на клиентах. А быть бета-тестером чужого кода - как-то желания нет, с федорой уже наигрался. Кроме всего прочего, как я понял из беглого просмотра инфы о vyatta, она не может жить на R/O накопителе или вообще без оного - а постоянная запись на DOM приведет к быстрой его смерти. Да и о стабильности - я почему-то на стабильность ни центоси, ни даже гентушных виртуалок со всяческим барахлом типа жабера/форума/etc не жаловался, а брасы/роутеры ребутятся только при обновлении софта или проблемах питанием. Что у "зачатка кластера" на CentOS, что у обеих виртуалок на нем - аптайм 188 дней, и падать не думают. А один из роутеров (еще на LEAF 3.1, 2.4 ядро) прожил без ребутов более года - пришлось ребутнуть когда апдейтили софт на нем, надо было поднять экстренно PPPoE ибо наша магистраль туда подгорела при пожаре, а апстрим, предоставившиий транспорт, не давал QinQ. Во-первых, начнем с того, что эдак с половину коммитов в LEAF v4 ветке - мои. Я пилил ее под наши задачи, моими усилиями там поселилось 2.6 ядро вместо 2.4 (соответственно с перекапыванием инит-скриптов); я апгрейдил тулчейн когда оказалось, что ядро почему-то криво собирается GCC 3.3.3 (не работала вафля), и позже, когда оказалось что GCC 4.4.4 тоже имеет баг - ядро падало в бсод через сутки; я туда впилил поддержку RFC3576 DM/CoA радиус-запросов для нормального изменения скорости (заняло собссно около недели), и т.п. Потому давайте не будет говорить о "профессиональном уровне" - наелся я уже "профессиональных" утечек памяти в ядре федоры и веселых глюков юзерлевела. P.S. Кстати, в vyatta имеется поддержка RFC3576? Или профессионалы не удосужились ее сделать?

Система выбирается под задачу. Надо стабильность/кластеризация без излишних усилий - CentOS (ну или Debian/Suse/etc - кому что ближе уже), надо свежий софт и мин. размер - Gentoo. Надо минимализм (те самые роутеры/брасы) - embedded дистр, который в необходимом конфиге влазит даже на 16МБ флэшку, и еженедельно бекапится целиком - так что при смерти накопителя/полном сгорании железки поднятие нового роутера/браса из бекапа дело нескольких минут. И главное - никаких винчестеров, которые не переносят мороз и жару.

Если вы не заметили, я об этом написал Угу, как и рэйд1. И разваливается при отказе 2-х. Открытие вы не сделали. Однако при наличии периодической проверки массива и при своевременной замене вышедших из строя накопителей (а не через полгода после обнаружения факта деградации) - надежность рэйда будет выше чем у одиночного SSD. Разве что для SATA3 накопителей. При этом мать еще должна поддерживать SATA3.

Да, насколько мне изместно - после 3 месяцев "тест-драйва" клиент должен заключить контракт на год. Таксказать, отработать потраченные на "тест-драйв" деньги

soft raid5 из подручных террабайтников (4шт - пара самсунгов, оба 7200 вроде, пара зеленых WD 5400) на домашнем тазике: # dd if=/dev/mapper/lvm--raid-www of=/dev/null bs=1M count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 2.01926 s, 260 MB/s По цене будет явно дешевле SSD. Ессно, при рандомном доступе - будет заметно медленнее. Впрочем, опять же, если вся ваша БД успешно кешируется в оперативку - то особо больших требований к быстродействию винтов не будет.

IFB к примеру. Или IMQ. Но для IFB - iptables уже не поможет, т.к. пакеты покинут интерфейс до обработки в iptables.

Осыпается, не спорю. о намного медленнее, чем винт. Возьмите винт, поставьте его под углом 45 градусов к столу, включите и постучите по нему пару минут рукояткой отвертки к примеру Уверен - после данного эксперимента винт будет годен только в помойку. А SSD - прекрасно переживет... Обычный винт потребляет от 5Вт (5400rpm 3.5") до 10Вт (7200rpm, из "быстрых" серий - те же WD black). Покажите мне SSD, которая будет кушать 0.5-1Вт, и при этом будет обладать сравнимой хотя бы с винчестером скоростью чтения/записи - я ее с радостью куплю в свой нетбук Файлохранилище с 16(!) винтами потребляло всего до 220...250Вт в режиме 100% нагрузки (по показаниям ваттметра на БП). В простое - 150 что ли... Ессно, первые 2 секунды после старта потребляемая мощность была более 400Вт - пока блины раскрутятся И это при том, что проц там стоял атлон 5600+ с TDP 95Вт.

Надежность - понятие растяжимое. При работе в режиме сильной вибрации - да, винт мгновенно осыпется, SSD же плевать. При работе в режиме постоянной перезаписи всей поляны - SSD издохнет за год-два. Особенно - MLC. Первые SSD были разве на лампах? Главный плюс SSD - отсутствие seek time как такового, ибо SSD все равно, откуда читать следующий сектор. И устойчивость к ударам (что для серверов ессно неактуально). P.S. По поводу энергопотребления: проц + мать будут кушать на порядок больше, чем винт/винты. Соответственно даже полное отключение винтов добавит максимум 10% времени работы от упса