Друзья! Кто заинтересовался заголовком прошу на GitHub, попробовать новую версию FastNetMon, где добавлена поддержка NetFlow, что позволяет фиксировать атаки на любой имеющейся инфраструктуре с минимальными телодвижениям: https://github.com/FastVPSEestiOu/fastnetmon :)
Wednesday 28 January 2015
Saturday 24 January 2015
Wednesday 21 January 2015
Новое слово в хранении данных - 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:
Также стоит отметить потрясающий уровень гибкости такого решения.
Добрые люди подсказали, что по похожей схеме устроен Google File System: https://ru.wikipedia.org/wiki/Google_File_System
Как многие знают, при очень большом числе дисков в массиве - 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Разве что стоит обратить внимание, что ZFS не умеет "жесткой" гарантии на размещение таких данных на разных дисках. Она лишь пытается, но не гарантирует.
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.
Также стоит отметить потрясающий уровень гибкости такого решения.
- Мы можем на лету добавлять диски, сколько угодно и никакого полного копирования данных.
- Мы можем свободно удалять диск из системы не заменяя его ни на что при наличии свободного места на другом массиве - все данные перетекут на свободное место
- Мы можем собирать массивы из разных по скорости дисков и при выделении нового volume указывать, что "разместить на пуле с SSD".
- Мы можем постоянно двигать блоки с диска на диск (например, как раз в случае потребности в более высокой скорости). Причем, это может осуществляться динамически (сама система переносит их на более быстрый сторадж)!
- При таком подходе даже теряя 3+ дисков, на которых размещен раздел мы теряем лишь разделы, размещенные лишь на этом диске! Но других разделов это не касается!
Добрые люди подсказали, что по похожей схеме устроен 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:
Для чистоты эксперимента нагрузка (тесты) с машины не снимается:
Насколько бажна эта машина и диски на ней? За последний год на ней диски менялись 12 раз! 2 раза менялся контроллер и 2 раза полностью пересоздавалась фс (ext4 поверх LSI/RAID-10) в связи с тотальным повреждением.
Итак, после недели работы и активной записи перезаписи ZFS-таки перешел в состояние DEGRADED!
И порадовал меня 23 тыщами ошибок записи на /dev/sdd:
zpool statusПри этом в dmesg творился настоящий ад!
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
[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
Tuesday 20 January 2015
Создание Linux Kdump поверх bonding
Настраиваем kdump как обычно, но добавялем в него опцию в файле /etc/kdump.conf:
options bonding mode=1Соответственно, режим бондинга меняете на свой!
Sunday 18 January 2015
Sunday 11 January 2015
Анализ блочной фрагментации на ploop дисках OpenVZ
Всем привет, друзья!
Нарисовал простенький (по этой причине - довольно медленный) анализатор места внутри ploop диска потерянного на "slick" (не занятые полностью куски блоков):
https://gist.github.com/pavel-odintsov/d5c37316e538908e0f01
Если у Вас на весьма крупных дисках будут большие цифры фрагментации - стоит задуматься о том, чтобы уменьшить размер блока ploop. К сожалению, пока силами vzctl этого не сделать, но можно сделать силами ploop и вручную пересоздать диск контейнера им.
Нарисовал простенький (по этой причине - довольно медленный) анализатор места внутри ploop диска потерянного на "slick" (не занятые полностью куски блоков):
https://gist.github.com/pavel-odintsov/d5c37316e538908e0f01
Если у Вас на весьма крупных дисках будут большие цифры фрагментации - стоит задуматься о том, чтобы уменьшить размер блока ploop. К сожалению, пока силами vzctl этого не сделать, но можно сделать силами ploop и вручную пересоздать диск контейнера им.
Subscribe to:
Posts
(
Atom
)