NiTr0

Lkz аутентификации пользователя по порту очевидно. Тупари без апгрейда до вланоподобных не поудйт. Или есть еще тут те, кто считает, что мак-адрес не меняется?

до 90Mbit видел на пптп интерфейсах юзеров. Только вот при трафике около 270Мбит итого и больше 350 юзеров, кампик на i5-560 (кажись) начинал подлагивать, при этом ядра были нагружены не более чем на 60%. О чем и речь. В то время как на ядерном пптп прекрасно бы этот тазик мегабит 500-700 с шейперами промолотил, если не гиг... В каждую из сторон ессно.

В МТ пптп в юзерленде. Со всеми вытекающими... Сомневаюсь, что вы с него много выжмете.

Ток неведомой формы с неведомым сдвигом относительно напряжения, если вы не осилили понять из контекста. Перестала. Смотрите пример про конденсатор. Ток - десятки ампер, мощность (активная) равна нулю.

Не так. По входу - синусоида, по выходу - невесть что и невесть как сдвинутое по отношению к напряжению.

U*I = 2 кВА, P=1.5кВт. Вывод-?

Воткните неполярный конденсатор на сотню-другую микрофарад в розетку. Измерьте ток. Посмотрите на стоящий на месте счетчик. Поудивляйтесь и подумайте, почему так вышло... После чего - примените полученные в результате размышлений знания к данному случаю, учитывая, что упс - с двойным преобразованием, и с cosф=1 в первичке.

1й - Вт 250 пожалуй будет кушать. 2й - до 200Вт.

Ну и что, что 800Вт БП стоят? Вскройте, посмотрите маркировку процов, посмотрите их TDP. Накиньте Вт 70 сверху на всякое охлаждение, память-чипсет и винты. Умножьте на 1.2 (потери в БП). Итого получите потребляемую сервером мощность с точностью % 10-15 - вполне достаточно для инженерных расчетов.

Для проверки превращали необслуживаемые в обслуживаемые с помощью подручных инструментов и какой-то матери? Может, проще было бы сразу купить обслуживаемые, с пробочками?

А чего просидеть-то? Вроде как в мускуле с экспортом-импортом бинарных логов все гладко и шелковисто, проблем особо нет. И да, если вы предлагаете таким образом шарить SAN - это еще помимо облачной вундервафли нужно будет завести отдельные сервера биллинга (основной и резерв), так? Итого минимум 2 SAN + минимум 2 контроллера облака + минимум 2 сервера биллинга, итого... И это к слову не обеспечит целостность данных при падении машины с мускулом к примеру - если в этот момент производилась запись в БД, на всех SAN получится битая база, требующая проверки/восстановления. Не совсем то, что нужн

У нас несколько брасов, лопатят до 500-600 мбит трафика в пике, сессий по 500-600, и шейпят там же, загрузку проца в пике как-то не смотрел - но до гигабита при аварии ранее брас молотил, хоть и юзерленд тупил (все ядро отжирало). И SSD ему ничем бы не помог. А убунта сервер - вообще без комментариев... Стыдится такого надо, а не гордиться этим.

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

А зачем на насе полноценная система? У нас и 128мб DOM с головой хватает. Без обычного винта. И тоже в рид-онли - система с него бутится и диск отмонтируется.

При падении сервера с данными данные, как это ни странно, тоже не теряются. Лежат себе спокойно, ждут пока их поднимут. А при настроенной репликации - вообще песня, данные синхронизируются везде... Накой городить огород из кучи машин (N серверов биллинга + M контроллеров облака), если достаточно простого кластера на 2 ноды, с pacemaker'ом в качестве CRM, мускулом в режиме мастер-мастер, и биллингом в виде мигрирующего ресурса? Разве что письками мериться, мол, "у меня биллинг в облаке личном живет"?

Что в лоб, что по лбу... Это сильно отличается от падения сервера с данными?

pacemaker, кластеризация, ну и мускул с репликацией ессно. После вдумчивого раскуривания - настраивается за 15 минут. В первыйй раз ессно несколько дней может занять изучение и эксперименты. И да, непонятно, как (и накой) абонент собссно к биллингу коннектится... Или это гибрид ужа с ежом биллинга с брасом? Так разнести нафиг в первую очередь.

Полтора скрипта на шелле. А по уму - ту же бакулу развернуть.

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

APFC некоторые к примеру без нее жить не могут...

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

Если SSD дохнет - инфу с него с большой вероятностью вытянуть не удастся. Вот и думайте, насколько целесообразно не использовать резервирование. И да, 2 SSD в рэйд1 скорее всего издохнут примерно в одно и то же время. Т.к. ресурс записи расходуется примерно одинаково у обеих. ИМХО целесообразнее будет заюзать flashcache.

Готов за 300 грн забрать все.

Может и легче, возьмем один на пробу, пощупать что за зверь.

Писал уже: врезается кулер, выводятся 6-10мм.кв. провода, уменьшается резистор для увеличения зарядного тока.