Система фиксации входящих и исходящих DDoS атак с поддрежкой sFLOW v5/NetFlov v5/v9 и mirror-портов - FastNetMon

Друзья! Кто заинтересовался заголовком прошу на GitHub, попробовать новую версию FastNetMon, где добавлена поддержка NetFlow, что позволяет фиксировать атаки на любой имеющейся инфраструктуре с минимальными телодвижениям: https://github.com/FastVPSEestiOu/fastnetmon :)

Супер быстрое конвертирование IP в обычной буквенной нотации в целочисленную с использованием SSE функций

Прошу:  http://blog.quarkslab.com/convert-ipv4-string-representation-to-a-32-bit-number-with-sse-instructions.html

Новое слово в хранении данных - BLOCK-RAID

Я довольно давно вынашивал эту идею и довольно странно, что она никем еще не реализована.

Как многие знают, при очень большом числе дисков в массиве - 12/24/48 или даже 96 стандартные режимы работы RAID (к ним я отношу 0/1/10/5/6) уже категорически неприменимы, ибо даже самый надежный RAID-6 дает совершенно неадекватные цифры по уровню надежности.

Разумеется, можно использовать совмещенные режимы, когда, например, RAID-0 собирается поверх нескольких RAID-6. Это немного улучшает ситуацию, но для кейсов 48/96 дисков по-прежнему не особо приятно себя ведет.

Кроме этого, очень мало реальных данных, которые будут эффективно разбросаны по 24м дискам (кейс RAID-6). Какой объем нужно записывать в среднем, чтобы он был разбросан по аж 24м дискам? Нереальный, согласитесь. А если писать на каждый диск по байту - тоже получится весьма и весьма печальная ситуация.

Кроме этого, редкий RAID даст собрать, скажем, 24х дисковый RAID-10 (тот же LSI ограничен 16ю дисками).

Намного более хорошая ситуация у нас с ZFS. Там есть режимы RAIDZ-1/2/3 которые в свою очередь являются аналогами RAID-5 (выдерживает отказ 1го диска) / RAID-6 (выдерживает отказ 2х дисков), а RAID-Z3 аналогов вовсе не имеет! Зато переживает отказ аж 3х любых дисков в массиве!

Но даже ZFS в чистом при большом числе дисков не панацея. Но если сделать, скажем ZFS stripe поверх десятка RAID-Z3, то можно достигнуть очень крутого уровня надежности и емкости!

Но если речь идет о хранении очень больших файлов, то самый гибкий вариант, который приходит в голову - это разбить файл на блоки и разбросать по N (2 и более) разным логическим устройствам!

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

Такой режим распределения данных используется в распределенном хранилище-mapdreduce кластере HADOOP (а также его реализации HDFS).

Но с учетом увеличения объемов локальных стораджей он вполне может быть использован и на локальных машинах и весьма успешно.

Конечно, такой режим приводит к 2-3х кратной потере места, но дает очень высокий уровень гибкости и полной независимости от числа дисков в массиве.

Но стоит отметить, что для случая механических дисков все не так очевидно - этот вариант будет точно очень плох для SATA и даже SAS. Но вот для SSD, когда скорости одного диска хватает почти любому приложению (а вот надежности - нет), будет просто идеален.

Стоит отметить, что такой режим можно легко реализовать с помощью Linux Device Mapper или же того же ZFS, с помощью использования опции copies:

copies=1 | 2 | 3
Controls the number of copies of data stored for this dataset. These copies are in addition to any redundancy provided by the pool, for example, mirroring or RAID-Z. The copies are stored on different disks, if possible. The space used by multiple copies is charged to the associated file and dataset, changing the used property and counting against quotas and reservations. Changing this property only affects newly-written data. Therefore, set this property at file system creation time by using the -o copies=N option.

Разве что стоит обратить внимание, что ZFS не умеет "жесткой" гарантии на размещение таких данных на разных дисках. Она лишь пытается, но не гарантирует.

Также стоит отметить потрясающий уровень гибкости такого решения.

1. Мы можем на лету добавлять диски, сколько угодно и никакого полного копирования данных.
2. Мы можем свободно удалять диск из системы не заменяя его ни на что при наличии свободного места на другом массиве - все данные перетекут на свободное место
3. Мы можем собирать массивы из разных по скорости дисков и при выделении нового volume указывать, что "разместить на пуле с SSD".
4. Мы можем постоянно двигать блоки с диска на диск (например, как раз в случае потребности в более высокой скорости). Причем, это может осуществляться динамически (сама система переносит их на более быстрый сторадж)!
5.  При таком подходе даже теряя 3+ дисков, на которых размещен раздел мы теряем лишь  разделы, размещенные лишь на этом диске! Но других разделов это не касается!

Пункт 5 на самом деле очень и очень важный потому что в классических RAID (что программных, что аппаратных) потеря дисков больше чем допустима для соотвествующего уровня RAID - фатальна, а для BLOCK RAID - это можно пережить - повредятся лишь затронутые данные! Это крайне актуально особенно в случае хранения нескольких тысяч терабайт данных. Безусловно, потеря 1/100 этих данных будет крайне неприятна, но это в миллион раз менее неприятно и фатально, чем потеря ВСЕГО массива!

Добрые люди подсказали, что по похожей схеме устроен Google File System: https://ru.wikipedia.org/wiki/Google_File_System

ZFS on Linux боевые тесты на бажном железе!

В контексте моей повальной увлеченности ZFS последние лет 7 решил поднять его на Linux да не просто поднять - а выбрать самую бажную машину из парка и поставить на ней.

Насколько бажна эта машина и диски на ней? За последний год на ней диски менялись 12 раз! 2 раза менялся контроллер и 2 раза полностью пересоздавалась фс (ext4 поверх LSI/RAID-10) в связи с тотальным повреждением. 

Итак, после недели работы и активной записи перезаписи ZFS-таки перешел в состояние DEGRADED!

И порадовал меня 23 тыщами ошибок записи на /dev/sdd:

zpool status
  pool: data
 state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
    repaired.
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    data        DEGRADED     0     0     0
      mirror-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
      mirror-1  DEGRADED     0     0     0
        sdd     FAULTED      3 23.0K     0  too many errors
        sde     ONLINE       0     0     0
      mirror-2  ONLINE       0     0     0
        sdf     ONLINE       0     0     0
        sdg     ONLINE       0     0     0

При этом в dmesg творился настоящий ад!

[919595.775408] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.775492] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 07 67 c7 40 00 00 08 00
[919595.775551] end_request: I/O error, dev sdd, sector 124241728
[919595.775622] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.775698] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 08 59 39 50 00 00 08 00
[919595.775756] end_request: I/O error, dev sdd, sector 140065104
[919595.775808] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.775884] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 09 15 92 b8 00 00 08 00
[919595.775940] end_request: I/O error, dev sdd, sector 152408760
[919595.775987] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.776061] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 09 24 1c 40 00 00 08 00
[919595.776118] end_request: I/O error, dev sdd, sector 153361472
[919595.776165] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.776240] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 08 56 f5 00 00 00 08 00
[919595.776297] end_request: I/O error, dev sdd, sector 139916544
[919595.776349] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.776424] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 06 40 4a 30 00 00 08 00
[919595.776481] end_request: I/O error, dev sdd, sector 104876592
[919595.776529] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.776605] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 02 7f ef 10 00 00 08 00
[919595.776662] end_request: I/O error, dev sdd, sector 41938704
[919595.776709] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.776783] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 09 3e 8d 98 00 00 08 00
[919595.776841] end_request: I/O error, dev sdd, sector 155094424
[919595.776889] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.776965] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 09 8a 21 a8 00 00 08 00
[919595.777021] end_request: I/O error, dev sdd, sector 160047528
[919595.777070] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919595.777145] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 08 86 97 80 00 00 08 00
[919595.777202] end_request: I/O error, dev sdd, sector 143038336
[919596.519092] megaraid_sas: scanning for scsi0...
[919610.884574] __ratelimit: 94 callbacks suppressed
[919610.884625] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919610.884691] sd 0:2:3:0: [sdd] CDB: Read(10): 28 00 00 00 0a 10 00 00 10 00
[919610.884741] __ratelimit: 94 callbacks suppressed
[919610.884776] end_request: I/O error, dev sdd, sector 2576
[919610.884821] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919610.884887] sd 0:2:3:0: [sdd] CDB: Read(16): 88 00 00 00 00 01 5d 3f b4 10 00 00 00 10 00 00
[919610.884969] end_request: I/O error, dev sdd, sector 5859423248
[919610.885009] sd 0:2:3:0: [sdd]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[919610.885075] sd 0:2:3:0: [sdd] CDB: Read(16): 88 00 00 00 00 01 5d 3f b6 10 00 00 00 10 00 00
[919610.885155] end_request: I/O error, dev sdd, sector 5859423760

После этого выполняем замену сбойного диска и ждем ресилверинга :)

Для чистоты эксперимента нагрузка (тесты) с машины не снимается:

 zpool status
  pool: data
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
    continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Jan 21 15:04:27 2015
    7.78G scanned out of 2.36T at 9.38M/s, 73h4m to go
    2.60G resilvered, 0.32% done
config:

    NAME             STATE     READ WRITE CKSUM
    data             DEGRADED     0     0     0
      mirror-0       ONLINE       0     0     0
        sdb          ONLINE       0     0     0
        sdc          ONLINE       0     0     0
      mirror-1       DEGRADED     0     0     0
        replacing-0  FAULTED      0     0     0
          sdd        FAULTED      3 23.0K     0  too many errors
          sdh        ONLINE       0     0     0  (resilvering)
        sde          ONLINE       0     0     0
      mirror-2       ONLINE       0     0     0
        sdf          ONLINE       0     0     0
        sdg          ONLINE       0     0     0

errors: No known data errors

Создание Linux Kdump поверх bonding

Настраиваем kdump как обычно, но добавялем в него опцию в файле /etc/kdump.conf:

options bonding mode=1 

Соответственно, режим бондинга меняете на свой!

Живое удаление устройств из пулов ZFS - отличная статья от Delphix

http://blog.delphix.com/alex/2015/01/15/openzfs-device-removal/

Анализ блочной фрагментации на ploop дисках OpenVZ

Всем привет, друзья!

Нарисовал простенький (по этой причине - довольно медленный) анализатор места внутри ploop диска потерянного на "slick" (не занятые полностью куски блоков):
https://gist.github.com/pavel-odintsov/d5c37316e538908e0f01

Если у Вас на весьма крупных дисках будут большие цифры фрагментации - стоит задуматься о том, чтобы уменьшить размер блока ploop. К сожалению, пока силами vzctl этого не сделать, но можно сделать силами ploop и вручную пересоздать диск контейнера им.