полезное по линуксу и iphone собрано все интересное мне лично (методом copy-paste из инета и не пыхтите насчет копирайта я ссылки на источник ставлю)

вторник, 12 апреля 2011 г.

LVM — это просто!

Собственно, хочется просто и доступно рассказать про такую замечательную вещь как Logical Volume Management или Управление Логическими Томами.Поскольку уже давно пользуюсь LVM-ом, расскажу что он значит именно для меня, не подглядывая в мануалы и не выдёргивая цитаты из wiki, своими словами, чтобы было понятно именно тем кто ничего о нем не знает. Постараюсь сразу не рассказывать о всяческих «продвинутых» функциях типа страйпов, снапшотов и т.п.

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

есть 3 уровня абстракции:
1. PV (Physical Volume) — физические тома (это могут быть разделы или целые «неразбитые» диски)
2. VG (Volume Group) — группа томов (объединяем физические тома (PV) в группу, создаём единый диск, который будем дальше разбивать так, как нам хочется)
3. LV (Logical Volume) — логические разделы, собственно раздел нашего нового «единого диска» ака Группы Томов, который мы потом форматируем и используем как обычный раздел, обычного жёсткого диска.
это пожалуй вся теория. :) теперь практика:
для работы нужны пакеты lvm2 и возможность работать с привелегиями root поэтому:
$ sudo bash
# apt-get install lvm2

допустим у нас в компе есть жёсткий диск на 40Гб и нам удалось наскрести немного денег и наконец-то купить себе ТЕРАБАЙТНИК! :))) Система уже стоит и работает, и первый диск разбит одним разделом (/dev/sda1 как / ), второй — самый большой, который мы только подключили — вообще не разбит /dev/sdb…
Предлагаю немножко разгрузить корневой диск, а заодно ускорить (новый диск работает быстрее старого) и «обезопасить» систему с помощью lvm.
Можно делать на втором диске разделы и добавлять их в группы томов (если нам нужно несколько групп томов),
а можно вообще не делать на диске разделы и всё устройство сделать физическим разделом (PV)

root@ws:~# pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created

Создаём группу томов с говорящим названием, например по имени машины «ws», чтобы когда мы перетащим данный диск на другую машину небыло конфликтов с именами групп томов:

root@ws:~# vgcreate ws /dev/sdb
Volume group «vg0» successfully created

желательно внести с корневого раздела такие папки как /usr /var /tmp /home, чтобы не дефрагментировать лишний раз корневой раздел и ни в коем случае его не переполнить, поэтому создаём разделы:

root@ws:~# lvcreate -n usr -L10G ws # здесь мы создаём раздел с именем «usr», размером 10Gb
Logical volume «usr» created
по аналогии делаем то же для /var, /tmp, /home:
root@ws:~# lvcreate -n var -L10G ws
root@ws:~# lvcreate -n tmp -L2G ws
root@ws:~# lvcreate -n home -L500G ws
у нас ещё осталось немного свободного места в группе томов (например для будущего раздела под бэкап)
посмотреть сколько именно можно командой:
root@ws:~# vgdisplay
информацию по созданным логическим томам
root@ws:~# lvdisplay
информацию по физическим томам
root@ws:~# pvdisplay

разделы что мы создали появятся в папке /dev/[имя_vg]/, точнее там будут ссылки на файлы,
lrwxrwxrwx 1 root root 22 2009-08-10 18:35 swap -> /dev/mapper/ws-swap
lrwxrwxrwx 1 root root 21 2009-08-10 18:35 tmp -> /dev/mapper/ws-tmp
lrwxrwxrwx 1 root root 21 2009-08-10 18:35 usr -> /dev/mapper/ws-usr
lrwxrwxrwx 1 root root 21 2009-08-10 18:35 var -> /dev/mapper/ws-var
и т.д…

дальше lvm уже почти кончается… форматируем наши разделы в любимые файловые системы:
root@ws:~# mkfs.ext2 -L tmp /dev/ws/tmp
root@ws:~# mkfs.ext4 -L usr /dev/ws/usr
root@ws:~# mkfs.ext4 -L var /dev/ws/var
root@ws:~# mkfs.ext4 -L home /dev/ws/home

кстати, не плохо было бы сделать раздел подкачки:
root@ws:~# lvcreate -n swap -L2G ws
root@ws:~# mkswap -L swap /dev/ws/swap
root@ws:~# swapon /dev/ws/swap

создаём папку и подключая по очереди новообразовавшиеся тома, копируем в них нужное содержимое:
root@ws:~# mkdir /mnt/target
root@ws:~# mount /dev/ws/home /mnt/target
копируем туда всё из папки /home своим любимым файловым менеджером (с сохранением прав доступа), например так ;):
root@ws:~# cp -a /home/* /mnt/target/
root@ws:~# umount /mnt/target/
кстати, для папки temp необходимо только поправить права, копировать туда что-либо необязательно:
root@ws:~# mount /dev/ws/tmp /mnt/target && chmod -R a+rwx /mnt/target && umount /mnt/target/
добавляем нужные строчки в /etc/fstab, например такие:
/dev/mapper/ws-home /home ext4 relatime 0 2
/dev/mapper/ws-tmp /tmp ext2 noatime 0 2
/dev/mapper/ws-swap none swap sw 0 0
и перезагружаемся… (продвинутые господа могут обойтись без перезагрузки ;))

На вкусное, хочу предложить более продвинутую штуку:
допустим у нас есть система с разделом на LVM, а жёсткий диск начал сбоить, тогда мы можем без перезагрузки переместить всю систему на другой жёсткий диск/раздел:

# On-line добавление/удаление жёстких дисков с помощью LVM (пример)

root@ws:~# pvcreate /dev/sda1 # наш эмулятор сбойного диска
Physical volume "/dev/sda1" successfully created

root@ws:~# pvcreate /dev/sdb1 # наш эмулятор спасательного диска
Physical volume "/dev/sdb1" successfully created

root@ws:~# vgcreate vg0 /dev/sda1 # создаю группу томов vg0
Volume group «vg0» successfully created

root@ws:~# lvcreate -n test -L10G vg0 #создаю раздел для «важной» инфы
Logical volume «test» created

root@ws:~# mkfs.ext2 /dev/vg0/test # создаю файловую систему на разделе
root@ws:~# mount /dev/mapper/vg0-test /mnt/tmp/ #монтирую раздел
… # заполняю его информацией, открываю на нем несколько файлов и т.п.

root@ws:~# vgextend vg0 /dev/sdb1 # расширяю нашу групу томов на «спасательный» диск
Volume group «vg0» successfully extended

root@work:~# pvmove /dev/sda1 /dev/sdb1 #передвигаю содержимое с «умирающего» диска на «спасательный»
/dev/sda1: Moved: 0.9%
/dev/sda1: Moved: 1.8%

/dev/sda1: Moved: 99.7%
/dev/sda1: Moved: 100.0%

root@work:~# vgreduce vg0 /dev/sda1 # убираю «умирающий» диск из группы томов.
Removed "/dev/sda1" from volume group «vg0»

Итого:
Я создал логический раздел, отформатировал его, примонтировал и заполнил нужными данными, затем переместил его с одного устройства на другое, при этом раздел остался примонтирован и данные всё время оставались доступны!
Подобным образом мне удавалось без перезагрузки перенести всю систему с умирающего диска на рэид-массив. :)

А это моя любимая ссылка по LVM: xgu.ru/wiki/LVM

P.S. Ах, да!!! Самое главное и самый большой минус LVM — он не читается grub'ом
поэтому раздел /boot должен находиться вне LVM на отдельном разделе жёсткого диска,
иначе система не загрузится.

Взято с http://habrahabr.ru/blogs/linux/67283/

понедельник, 7 февраля 2011 г.

Активируем отключенный VT-x

Написал однажды мне друг с ноутбуком Samsung r60. Процессор в этом ноутбуке поддерживает аппаратную виртуализацию, но по умолчанию она отключена, и пункт включения в биосе отсутствует. Биос — Phoenix. Мы не будем патчить биос, мы будем патчить NVRAM!

Нам понадобятся:
• Samsung's FW Modules Extractor
• Phoenix BIOS Editor
• SYMCMOS — читалка/писалка cmos
• NDISASM — дизассемблер x86 кода
• Загрузочная флешка/дискета с DOS

Ну что ж, приступим!
Качаем прошивку с сайта Samsung. Прошивка идет одним .exe файлом вместе с прошивальщиком, нужно достать сам файл прошивки. Для этого воспользуемся Samsung's FW Modules Extractor



Не все файлы распаковались, но это не важно.

Открываем прошивку в Phoenix BIOS Editor, сворачиваем его и достаем файлы BIOSCOD*.ROM из папки TEMP Phoenix BIOS Editor'а. Он распаковал нашу прошивку. Копируем файлы в другую папку, закрываем Phoenix BIOS Editor.

Начинается самое интересное. Дизассемблируем файлы из прошивки, в моем случае их было 7 (0-6):
$ for i in {0..6}; do ndisasm -a -p intel -b 16 BIOSCOD0$i.ROM > BIOSCOD0$i.dasm; done

Путем гугления выяснилось, что искать нужно команду mov ecx,0x3a:
$ grep 'mov ecx,0x3a' *.dasm
BIOSCOD04.dasm:0000BE99 66B93A000000 mov ecx,0x3a

Отлично, команда найдена в файле BIOSCOD04.dasm!

0000BE99 66B93A000000 mov ecx,0x3a
0000BE9F 0F32 rdmsr
0000BEA1 668BD8 mov ebx,eax
0000BEA4 83E305 and bx,byte +0x5
0000BEA7 B86F06 mov ax,0x66f
0000BEAA 9A355400F0 call word 0xf000:0x5435
0000BEAF C1E002 shl ax,0x2
0000BEB2 40 inc ax
0000BEB3 38D8 cmp al,bl
0000BEB5 7432 jz 0xbee9

Из кода видно, что в регистр ax записывается значение по адресу 0x66f, выполняются сравнения между al и bl, и если оба значения совпадают — прыгаем на адрес 0xbee9 — адрес отключения виртуализации.

Пришло время SYMCMOS. Создаем загрузочную флешку/дискету, записываем программу на носитель, загружаемся и выполняем
symcmos -v2 -lNVRAM.TXT
Теперь у нас есть файл nvram.txt примерного содержания:
( SYMBOLIC CMOS EDITOR - Version 643710-035 )

CRC = 350F
(0015) [0000]
(0018) [0001]
(001B) [0001]
(0021) [0000]
(0024) [0001]
(0027) [0001]
(002A) [0000]
(002D) [0001]
(0030) [0000]
(0036) [0000]
(0039) [0000]
(003F) [0001]
(0042) [0000]
...
(066F) [0000]
(0672) [0000]
(0675) [0000]
(0678) [0002]
(067B) [0000]
(067E) [0000]
(0681) [0002]

Видно, что значение параметра, отвечающего за виртуализацию, установлено в 0. Изменим его прямо в этом файле:
(066F) [0001]
Опять загрузимся в DOS и выполним:
symcmos -v2 -uNVRAM.TXT

Перезагружаемся. Та-дам! Аппаратная виртуализация активирована!

Интересные ссылки:
http://tjworld.net/wiki/Sony/Vaio/FE41Z/HackingBiosNvram — программа для активации VT-x без прошивки CMOS для linux
http://forum.notebookreview.com/acer/465936-acer-laptop-phoenix-bios-enable-virtualization-test-machine-acer-aspire-9420-a.html — С чего все начиналось

Взято с http://habrahabr.ru/blogs/DIY/113223/

суббота, 8 января 2011 г.

MySQL: Slave could not parse relay log event entry

При использованиии MySQL Master-Slave (или же Master-Master) репликации бывает ситуация что по разным причинам версия слейва ниже чем версия мастера.
Если при этом используется опция binlog_format=MIXED, в результате возможна ситуация когда мастер запишет в свой binlog запись вида:
BINLOG 'XMawShMEAAAARwAAAEp5UwUAAGkAAAAAAAAACHNhblahblahblah'
Которую слейв не сможет выполнить, ибо он ее попросту “еще не умеет”.
Первой ласточкой того, что это произошло станет сообщение “SLAVE DOWN” от мониторинговой системы и запись в MySQL-логе слейва сродни этой:
090917 14:55:51 [ERROR] Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 71, event_type: 19
090917 14:55:51 [ERROR] Error reading relay log event: slave SQL thread aborted because of I/O error
090917 14:55:51 [ERROR] Slave: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' o
n the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL
code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 0
090917 14:55:51 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'bin-us1.000022' position 17007149

Попытки пропустить неугодные записи старым добрым методом:
slave stop;
set global sql_slave_skip_counter=1;
slave start;

в данном случае не помогают.
Как вариант решения предлагаю:
  1. Останавливаем slave: “SLAVE STOP;”
  2. “Выуживаем” из текста ошибки имя бинлога и позицию, на которой произошла ошибка.
    В данном случае это bin-us1.000022 и позиция 17007149
  3. На мастере выполняем запрос “FLUSH LOGS;”
  4. Делаем дамп бинлога начиная с найденной позиции:
    mysqlbinlog --start-position=17007149 bin-us1.000022  >  bin-us1-from17007149.sql
  5. Загружаем полученный дамп на слейве с ключем “–force”
    mysql --force -uuser -ppassword database < bin-us1-from17007149.sql
  6. Выполняем на слейве “FLUSH LOGS;”
  7. В data-директории находим relay-log с максимальным номером и размером около 100 байт (в моем случае это mysqld-relay-bin.000037)
  8. В той же директории в файле relay-log.info
    первую строку заменяем на имя только что найденного relay-log-а, во вторую вписываем 0, в третью – следующий после “испорченного” бинлог, в четвертую – 0
    Получится что-то вроде:
    /var/lib/mysql/mysqld-relay-bin.000037
    0
    bin-us1.000023
    0
  9. Дальше на слейве выполняем:
    CHANGE MASTER TO MASTER_LOG_FILE='bin-us1.000023', MASTER_LOG_POS=0;
    SLAVE START;
  10. Ну и потом чтоб удостоверится что все “завелось”
    SHOW SLAVE STATUS\G
Должно работать.
Подозреваю что пункты 4 и 5 можно обьеденить в один, более простой и элегантный.
Но как это сделать – не гуглил.

Оригинал

вторник, 30 ноября 2010 г.

RabbitMQ: Введение в AMQP

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

И вот, в один прекрасный день, собрались инженеры с духом, и разработали AMQP — Advanced Message Queuing Protocol. Этот протокол позволяет не задумываться над тем, где находятся получатели сообщения, сколько их, от кого надо ждать сообщение, когда оно будет доставлено получателю. Кроме этого, AMQP снимает с разработчика ещё многие рутинные задачи и позволяет заниматься непосредственной проблемой, а не обслуживанием процесса разработки.

AMQP имеет три базовых понятия:
  • Обменник (exchange)
  • Очередь (queue)
  • Связь, или маршрут (routing key)

Обмен сообщениями осуществляется в пределах одного обменника (есть ещё цепное связывание, но об этом в другой раз), в котором определены связи, являющиеся своеобразными маршрутами, по которым идут сообщения, попавшие в этот обменник. Каждый маршрут связывает обменник с одной или несколькими очередями. Программное обеспечение, реализующее описанные действия, называют AMQP-сервером. Узлы, помещающие сообщения в обменники и получающие их из очередей, называются AMQP-клиентами. Другими словами, AMQP-сервер предоставляет шину обмена данными, а AMQP-клиенты используют эту шину для обмена сообщениями между собой.
Клиенты могут создавать новые обменники (об их типах поговорим позже) и очереди:
Exchange.Declare  TYPE 
Queue.Declare 

Процесс помещения данных на шину называется публикацией. Когда AMQP-клиент публикует сообщение на шину, он задаёт имя обменника и имя связи:
Message.Publish  TO  WITH 

До этого момента, один из клиентов должен осуществить связку, указав имя обменника, очереди и маршрут, соответствующий ей:
Queue.Bind  TO  WITH 

В результате, сообщение будет доставлено в очередь .Но на этом ещё не всё, так как путь сообщения очередью не заканчивается. Один из AMQP-клиентов подписывается на получение сообщений, попавших в заданную очередь:
Queue.Subscribe  TO 

где — идентификатор процесса. Здесь и далее работа с AMQP будет описываться с точки зрения программирования на Erlang, в реализациях клиентов на других языках сообщения вычитываются из очереди явной инструкцией, либо вешаются коллбэки и подписки как таковой нет. После подписки на очередь, все сообщения, попавшие в неё, будут пересылаться подписанному процессу. Если на одну очередьподписано несколько процессов, сообщения будут распределяться по подписчикам методом round-robin.

Для получения ответа, при отправлении запроса в свойствах сообщения заполняется полеReply-To, содержащее, как правило, очередь приватного типа, на которую подписан только отправитель.

На этом пока всё, в следующий раз постараюсь написать про типы обменников и показать примеры кода, хотя посмотреть их можно уже сейчас вот здесь


Оригинал: http://habrahabr.ru/blogs/erlang/64192/

Два твика для ускорения Cydia и iPhone

Cydia – отличный менеджер пакетов для iPhone, iPod touch и iPad с джейлбрейком. Но по умолчанию программа работает слишком медленно. Сегодня мы покажем как легко можно ускорить Cydia и любой “яблочный” гаджет с джейлбрейком.

Отключение автоматического обновления Cydia

Автоматическое обновление в Cydia – одна из самых надоедливых функций программы. Cydia настойчиво обновляет базу репозиториев при каждой загрузке, и при большом количестве источников это сильно замедляет старт программы.
Далее инструкция по отключению автоматического обновления репозиториев в Cydia:
Шаг 1: Запустите Cydia и в разделе Search найдите и установите утилиту SBSettings.
Шаг 2: Во вкладке Sources добавьте источник http://repo.modyouri.com/.
Шаг 3: Вернитесь в раздел Search, найдите утилиту “NoCyfresh i4″ (или “NoCyfresh i3″, если у вас iPhone 3G или 3GS) и установите ее.
Шаг 4: Откройте SBSettings (по умолчанию свайп по строке статуса iOS). Включите опцию NoCyfresh.
Шаг 5: Не закрывая SBSettings, нажмите кнопку Respring.
Шаг 6: Теперь Cydia будет открываться очень быстро и зависания со строчкой Refresh Database пропадут. Если вам понадобится обновить репозитории, то сделать это можно вручную. Для этого в Cydia в разделе Changes достаточно нажать Refresh.

Отключение баннеров на уровне iOS

При просмотре любого пакета в Cydia подгружаются различные ссылки, описания, баннеры, логотипы и т.д. Это существенно замедляет работу приложения. В одной из прошлых статей мы рассматривали как отключаются баннеры в Cydia через SSH. Однако твик SBAdBlockToggle избавляет от всех этих сложностей. При этом SBAdBlockToggle блокирует баннеры на уровне операционной системы!
Шаг 1: Если вы уже подключили источник http://repo.modyouri.com/ для первого твика, то запустите Cydia и во вкладке Search найдите и установите утилиту SBAdBlockToggle.
Шаг 2: После Respring в SBSettings появится значок Adblock. Нажмите у удерживайте его до перезагрузки своего iPhone, iPod touch или iPad.
Шаг 3: Теперь, при просмотре любого пакета в Cydia вы заметите разницу в скорости его запуска. Как я уже говорил, SBAdBlockToggle отключает баннерную рекламу на уровне iOS. Другими словами баннеров не будет во всех приложениях, загруженных из Cydia, App Store и даже разработанных Apple, например Safari!

Источник: http://www.macdigger.ru/iphone-ipod/dva-tvika-dlya-uskoreniya-cydia-i-iphone-dzhejlbrejk.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Macdigger+%28MacDigger.ru%29

Играем с BGP в Quagga

1 комментарий

Комментарий от: Andrew A. Sabitov [Посетитель]
Всё карачо, но не рассмотрен самый частый случай: Ваша АС с БГП-раутером + 2-3 аплинка к провайдерам. Всё настроено по варианту 3, всё работает, а потом у одного из провайдеров падает _его_ (единственный!!!) аплинк. Картина маслом...

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

router bgp 25549
bgp router-id 217.70.98.105
network 195.49.168.0/22

!default AS (Electrosvyaz)
neighbor 217.70.98.106 remote-as 16054
neighbor 217.70.98.106 description Sibirtelecom aka Elektrosvyaz
neighbor 217.70.98.106 filter-list 21701 out
neighbor 217.70.98.106 filter-list 21700 in

! ZSTTK AS
neighbor 81.1.255.45 remote-as 21127
neighbor 81.1.255.45 description ZSTTK
neighbor 81.1.255.45 filter-list 8101 out

ip as-path access-list 21701 permit ^$
ip as-path access-list 21701 permit 25549$
ip as-path access-list 21701 deny .*

ip as-path access-list 21700 deny 21127$
ip as-path access-list 21700 deny 20651$
ip as-path access-list 21700 permit .*

ip as-path access-list 8101 permit ^$
ip as-path access-list 8101 permit 25549$
ip as-path access-list 8101 deny .*

Оригинал: http://blog.peter.am/index.php/2010/11/27/bgp-quagga

Linux на службе у провайдера

Просмотрев большинство тематических постов на хабре был безмерно удивлён тому факту, что крайне скудно освещена тема использования ОС Unix/Linux на службе интернет провайдеров (Internet service provider). Данной статьёй я частично попытаюсь восполнить данный пробел.


Почему в сети интернет наблюдается полное отсутствие таких статей догадаться не сложно — всех кто использует Linux/FreeBSD в ISP сразу же обвиняют в нищебродстве и советуют купить Cisco или уж на совсем крайний случай Juniper. Именно поэтому вторая цель данной статьи показать читателю, что некоторые технические решения на базе ОС Linux по многим показателям на порядки превосходят брэндовые решения от самых известных вендоров.


Шейпинг

Наш первый опыт «нестандартного» использования Linux появился сразу после начала предоставления услуг широкополосного доступа для физических лиц. Необходимо было чем-то «порезать» внешний канал каждого из наших пользователей. Здесь ввиду отсутствия собственных наработок на данную тему пришлось изобретать свой собственный велосипед применяя cbq и собственной обвязки к нему. Данная схема проработала пару месяцев пока мы не осознали всех ее минусов и не упёрлись в производительность машины.

Все дело в том, что система начала «съедать» слишком много soft interrupts даже при не большом трафике, на вскидку при транзитном трафике в 300 мегабит и 30 kpps при 1000 линейных правил cbq (по 2 правила вход/выход на пользователя) на каждом интерфейсе в top si достигал 100%.

Если бы в данный момент перед нами бы встала та же самая задача при тех де самых технических средствах мы бы решали ее с помошью Linux htb tc + хэш фильтры.

NAT

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

Остановились на «серых» адресах, т. к. при их использовании существенно экономился столько ценных на тот момент материал как реальные адреса. Также несколько повышалась безопасность и комфортность работы наших пользователей, т. к. извне их компьютеры не были доступны всей сети интернет «напрямую».

Для NAT-а было выбрано оборудование Cisco в частности Cisco ASA 5505 — на тот момент ее мощности было достаточно чтобы покрыть потребности наших клиентов.

В то же самое время ВДРУГ появилась информация, что заказанная нами Cisco ASA несколько подзадержится, и собственно встал вопрос чем от NAT-ить 100Мбит/с поток.

«На коленке» был собран тестовый стенд из обычного офисного PC-ка с 2 сетевыми гигабитными адаптерами и выяснилось, что при небольшом тюнинге этот самый обычный «писюк» с самыми обычными реалтеками способен отнатить нужный нам поток.

После замены железа через один из наших NAT серверов в пиках проходило 1800 мбит/с (да, да это не описка, трафик почти 2 гигабита/с) при сравнительно небольшой нагрузке на систему.

NETFLOW

Столкнувшись с проблемой сбора статистики работы домашних пользователей до NAT-а т. е. c «серыми» адресами пришли к простейшей схеме получения статистики NETFLOW.

Собрали схему при которой мы «выгоняем» копию всего трафика пользователей (SPAN PORT) в нужные сетевые порты сервера с ОС Linux на борту, а далее с помощью ipt_NETFLOW формируем поток FLOWS на нужный сервер.

Более подробно вместе с конфигами схема работы приведена здесь.

P.S. Мы в курсе, что большинство оборудования Cisco может лить уже сформированный NETFLOW поток в указанный Netflow коллектор, но в нашей схеме сети на тот момент такого оборудования просто не могло быть :)

Терминация пользовательских сетей.

Изначально хотелось дать пользователю ip адрес, маску подсети, и шлюз и не грузить его настройками PPPoE, PPTP, VPN что в конечном итоге должно было несколько разгрузить службу технической поддержки (что и произошло на практике), так как настройка сети становилась достаточно тривиальной в любой пользовательской ОС.

Решив применить наш предыдущий опыт использования ОС Linux пришли к следующей схеме, в ключевых местах сети устанавливаются Linux сервера с парой четырех-портовых сетевых адаптеров, один линк «уходит» в сторону ядра сети остальные в сторону «кластеров». В результате на каждом интерфейсе поднимается куча VLAN-ов с несколькими сетями в каждом из них.

Всего у нас на всю сеть было 4 сервера примерно по 10k абонентов на каждом.

Пиковый трафик достигаемый каждым сервером в часы пик стремился к полутора мегапакетам в секунду. Сервера обменивались друг с другом маршрутами по протоколу ospf.

Блокирование доступа пользователям осуществлялось с помошью ipset.

Бордер

Тут бы на этой счастливой ноте и закончить, но хочется написать о еще одном «не стандартном» применении Linux — в качестве бордера. Так получилось, что у нас вышла из строя Cisco ASR выполняющая функции бордера на который приходило 2 full view от двух аплинков.

Здесь следует небольшое лирическое отступление. Компания Cisco на 100% сдержала свои обязательства и выслала замену в течении нескольких часов после заполнения необходимых документов, но как Вы понимаете клиенты не будут ждать сутки пока новое железо прилетит в наши края. Решение было спонтанным.

Со склада взяли сервер установили на него Linux + quagga и благополучно поставили вместо вышедшей из строя Cisco.

В час пик это чудо инженерной мысли «прожевало» входящий поток 1.4Гбит/c, при суммарном kpps на всех интерфейсах порядка 400.

P.S. В ходе работы нами было собрано и протестировано множество RPM пакетов для дистрибутива CentOS 5 вот лишь небольшой их список:
  • ipset
  • connlimit
  • conntrack-tools
  • ipt_netflow
  • flow-tools
  • quagga


Cкачать их можно из данного репозитория.

P.P.S. Если у Вас есть свои собственные наработки или заметки по поводу использования *nix like OS на службе ISP, добро пожаловать.

Оригинал: http://habrahabr.ru/blogs/sysadm/106932/