NiTr0

Кстати, на рутрекере в топике имени киевстара вроде как проскакивала "типа инсайдерская" инфа о том, что с НГ будет некий "акционный" тариф, 80 грн/80 мбит, который просуществует до 1 января 2013г. Очередная попытка привлечь абонов от мелких провов, или "утка"?

Очевидно, "персональными данными" будут считаться и телефонные справочники, и записные книжки (в т.ч. в телефоне), и газеты с объявлениями (да-да, по ФИО и номеру телефона, которые там указываются, можно идентифицировать человека), и т.п...

ИМХО наоборот - жоско и со вкусом стебутся

Не нужно поднимать панику. Да, NIDEC пострадал - но не так уж и сильно, ибо пр-ва у него не только в Таиланде. "Форсировали" прочие производственные мощности, хоть и не до прежнего уровня, но все же подняли выпуск. Говорят, ожидается уменьшение выпуска движков порядка 30% А то, что пресса старательно газирует лужи, описывая IT-апокалипсис - собссно выгодно всем: и крупным оптовикам, которые закупают партии с выросшей на % 10-20 (встречал такие данные) ценой, а продают дороже на 100-200%; и вендорам (прибыль растет, особенно - у тех, чьи заводы не пострадали), и средним/мелким оптовикам, для которых это шанс распродать неликвид 80-320ГБ... Не выгодно только покупателям

это не x86, а тем более всего 400Мгц. Нет, это таки непродуманный учет траффика Очевидно что-то сродни netflow юзерлевельное. Хотя для учета достаточно было бы создать правила иптейблса (да-да, микротик - linux-based) вида -A FORWARD -s <ip> без какого-либо действия, и с них снимать статистику по отловленному траффику раз в минуту скажем. Практически бесплатно с т.з. ресурсов. Да хоть 100 машин, если на них юзеры читают вконтакте/сидят в аське. как однако все печально с т.з. стабильности...

Купить к нему за пиво/символические деньги DIR-100 к примеру, оставив модем - модемом, а роутер заюзав роутером/натом, и возрадоваться - вариант не катит? Все равно этот уродец стабильно более 30-50 tcp сессий не пережует...

Лучше 2 человека. Или лучше часть рутинной работы (конфигурирование свичей и т.п.) поручать дежурным инженерам. Сварочные работы должны уметь выполнять и монтажники, пускай не все - но сварщиков должно быть 2-3 человека. Потому как если один уехал в отпуск/заболел, и порвалась магистраль - будет печально. Тем более - это не высшие материи, неделя практики для адекватного человека - и сварщик готов. Он же ИМХО и должен принимать решения по развитию сети. Возможно - в виде совещания с прочими инженерами. Или PBX внутреннюю + саппортеры-аутсорсеры (вменяемые ответственные студенты к примеру - таковые еще встречаются). В договоре оговорить платность вызова по вине абонента. Продемонстрировать, что на ноуте все прекрасно работает, а что творится у абонента - его личные проблемы, которые вы можете решить за отдельную плату. + оплата за ложный вызов. Не нравится - пускай идет выедать мозги конкуренту. Тем более, такие зачастую пользуют самые дешевые пакеты.

Не знаю как насчет PPPoE терминации (все же ресурсоемкая задача), но просто транзит симметричного траффика думаю вполне пережует. + по поводу PPPoE - RPS включите на всех очередях, туннели по очередям не распараллеливаются.

Разнесите зоопарк на 2 тазика хотя бы. Тогда может и прокачает. Думаю, догадываетесь же, что случится с юзерлендом (т.е. биллинг/радиус/прочее) если ядро 100% времени откушает?

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

ИМХО - софт-рэйд. Ибо не зависит от глюков конкретного рэйд-контроллера (где-то читал о случае, когда контроллер ребилдил массив посчитав актуальным ранее отпавший диск), легче собирается в случае разваливания, без проблем мониторится, и не зависит от железа (сдох контроллер - переключить в любой другой). 1, 2) Что угодно. В идеале - рид-онли флэш, ось в RAM, + еженедельные бекапы. У нас так. Хуже - 1 диск или рэйд, без свопа. 3) Рэйд-массив, + достаточно памяти чтобы БД жила в кеше. 4) См. 1). Хотя я не виду смысла делать его отдельно. Даже 500 запросов в секунду не смогут создать ощутимую нагрузку на какой-то атом. Система на SSD - ИМХО бред, смысла 0. На БД - можно, в рэйд1, хотя я очень сомневаюсь в целесообразности. Особенно на 2к абонов. 10-20к, когда все упрется в БД - возможно и придется. Горячая замена = AHCI hotplug. Уведомления о degraded array mdadm прекрасно шлет. + если сильно хочется надежности - добавляете один spare диск, или таки рэйд6. Угу. Со звездочкой, а ниже мелким шрифтом - в идеальных условиях, при записи блоками равными размеру физ. блока SSD, при условии того что на диске занят ничтожно малый объем, и т.д. И часы - ничто, кол-во записей решает. К слову, десктопные SSD весьма успешно мрут, не смотря на то, что вроде как не должны...

10Вт - касалось суммарного потребления винчестера. А вообще - ИМХО пенек будет кушать заметно меньше чем его заявленый TDP. Потому как i5, если память не подводит, в этот TDP укладывается... Скорее всего БП справится, для уверенности - можно взять трупик китайского БП, отстегнуть от него шнурки питаний, и собссно подать через них с включенными в разрыв амперметрами питание.на мамку с процом/памятью. И пустить какую-то ресурсоемкую задачу (к примеру, корки 2 лучше всего грел OCCT). Думаю, по +12 от силы ампер 5 будет кушать...

Родной БП 3.3В/5А. Т.е. - на этот номинал и рассчитывать ИМХО, если "по правилам".

Не все. Проц - +12, чипсет - +12 или +5 основное питание, + еще от 3.3В кучка напряжений, память - сугубо +5 (да-да, иначе о S3 забыть можно), винт - где-то в соотношении 2:1 +12/+5 кроме старта (тогда - до 2-3А), и в сумме Вт эдак 10 от силы. AMD - смотрите TDP, за пределы его не вылезут в любом случае. Чипсет кушает мало ИМХО (Вт до 5-6).

Да, еще, при разработке бизнес-плана ориентируйтесь на постепенное разрастание сети. Не обязательно сразу же строить "как надо" (IPoE на новых управляемых коммутаторах с DHCP snooping, аппаратные бордюры и т.д.) - может, проще будет сначала по мере роста кол-ва абонов переходить с каких-то TL-SG2210WEB на что-то более многопортовое, а снятые свичи ставить в 2-этажные дома... Ну и туннели + сегментация влан на дом (либо, хуже вариант - привязка ip+mac, при малых сегментах вполне жизнеспособна). Ядро - тоже строить на писюках, с подбором железа и резервированием.

Есть. Под AMD правда - там не так все печально. Ну и ессно нерегистровая (дешевле к тому же). Хотя на брасах я сомневаюсь в острой необходимости в ецц памяти. Биллинг/БД - да.

Смотря что абонам нужно, насколько они голодные и т.п.. В ЧНН при накачаных абонентах и при толстых каналах (десятки мбит/с) в среднем приходится 1 мбит на одного онлайн абона, онлайн - 50% от общей активной абонбазы. Но это - для более крупных сеетй, чем меньше сеть - тем больше флуктуации. Ессно, на бордюре некий шейпер с приоритезацией по классам будет совсем не лишним - для незаметного сглаживания полки (которая вполне может случаться - даже у более крупных сетей может быть пик в ЧНН в +50-70% от типичного, правда - кратковременный, но все же его нужно пережить без существенного снижения качества услуги - тубы/скайпы/игры не должны лагать при этом). Как минимум - возьмите вместе с ним канал тогда уже. Дешевле в итоге будет, да и коэф. мультиплексирования суммарный в итоге повыше будет (меньше внешнего канала потребуется, чем раздельно).

Главный вопрос - а есть ли возможность взять дешевый интернет-канал на мир и еще более дешевый на Украину, в объеме скажем до 1-2 гигабит в перспективе? Ну и + попутно можно обвафлить частный сектор (+ новые клиенты, + прибыль, расходов же - не так и много).

В общем-то все не так печально, с приходом RPS в ядра. Но равномерной балансировки все равно не получится - хотя может в свежих ядрах RPS более адекватно работает по сравнению с .35

Если не ошибаюсь - там 1 полноразмерный PCI слот боком через райзер.

Есть смысл в 2 (или более) насах, а не в одном большом монстре. Дешевле будет. + нагрузка на проц растет нелинейно. Насчет бордюра - думается, одна голова, даже не самая топовая, если без ната, прожует далеко не один гиг...

После эдак месяца аптайма его начинает занятно пучить - к примеру, может начать срать DHCP в WAN порт. От торрентов ессно дохнет. Как бюджетный вариант - asus rt-g32 C1, перешитый в wive-ng (как минимум от торрентов не будет таращить - в отличие от большинства прочих роутеров). Дешевле - разве что 802.11g будут. Ну или DIR-300/DIR-620, опять же перешитые в wive.

Именно Powercom BNT? У меня с ними никаких проблем не было. Не одну штуку переделывал.

LGA771 с Core2 зеонами в эту категорию попадает - но в принципе еще вполне юзабельно. Насчет сокета 603/604 - то да, брать разве что из любви к искусству, ибо по производительности будет сопоставимым с атомом, и сольет любому младшему 2-ядерному десктопному процу; по надежности/безглючности же б/у сервер не слишком далеко ушел от десктопа - как минимум контакты имеют свойство окисляться, кулера - изнашиваться, конденсаторы - деградировать со временем, даже брендовые.

1 - думаю какого-то одноголового зеона на 4 ядра по 2.5-3 ГГц с головой (у нас 2-головый феном спокойно пережевывает украины под 1.2гига в сумме ап+даун в пике с солидным запасом), хотя если с перспективой расширения - можно поставить плату с 2 сокетами, но пока поставить только 1 проц. 4 - минимум 2 сервера. Можно менее мощных. Зеоны на 4-6 ядер ИМХО вполне подойдут. Далеко не все отказы случаются по вине железа - грабли с софтом никто не отменял. Да и останавливать один из них на ревизию/апгрейд/апдейт софта - намного проще, в 5 утра остановить PPPoE демон с дропом всех туннелей - и никто не заметит даже... 5 - аналогично, лучше 2 железки с VRRP между ними. 6 - выделенный ИМХО смысла нет, лучше поднять на серверах/брасах/бордюре. Причина - малая нагрузка на проц (у вас же сеть не на 100к+ абонов?), и в то же время относительно большой аппетит к памяти (которой на брасах к слову обычно в избытке - особенно при пользовании специализированных дистров с uClibc вместо грузных комбайнов). А вообще - я бы советовал из серверов с биллингом и БД сваять кластер. Одна нода - в штатном режиме БД, вторая - логика биллинга; краш одной из нод - сервисы поднимаются на второй автоматически. Потому как в противном случае разнесение сервисов с одного сервера на два приводит не к увеличению надежности, а к падению ее Вероятность отказа одной железки из двух в два раза выше, чем отказа одой железки из одной