1) Вы противоречите сами себе, но ничего, для 3 копий — DRDB можно растянуть на 3 сервера, для обычных на 2 — делаем тогда комбинированный RAID тогда будет доступно — 19*3 = 57TB/(2+3)*2 = 22.8TB доступно, с учетом накладных затрат где-то 21TB
2) тоже самое — если БЫ Вы захотели увеличить например RAID5 или RAID6 увеличение просто-так невозможно, соответственно количество серверов должно расти пропорционально количеству нодов в корзине
Если так нужно САР — то смотрите в сторону Riak — скорее всего выбере именно его.
А что Вам мешает управлить пространством в UNIX стиле?
т.е. Вы далаете 2 раздела: (1) mission critical — DRDB(RAID1)+OCFS2 (2) default — OCFS2 итого будет 19TB (2x19TB@DRDB-RAID1) + 19TB (default) = 38TB ~место под метаданные (не более 5%) т.е. физически будет доступно около 36TB
далее понтируете в точку например /mnt/netfs/critical/ для критических данных и /mnt/netfs/default/ для обычных данных
критичные данные ВСЕГДА будут иметь 2 копию, обычные НЕ будут ее иметь
OCFS2 позволяет Вам получить обычную ФС которая будет «размазана» по нескольким нодам, также Вы можете добавлять новые ноды для увеличения пространства. ФС умеет работать с блоками файлов (как pNFS4)
у Basho Riak есть только 1 проблема — это вероятность «split-brain» в случае сетевых проблем, а так сама БД очень гибках — с множеством backend моделей для физического хранения данных.
Я не понимаю причем тут 25TB данных и шардинг. Вы хотите получить (1) отказоустойчивость — ее обеспечивает DRDB как RAID1 через сеть (2) распределенность — тут OCFS2
Почему-же? Через OTP меняете каждый раз пароль и все, или например использовать аналога E-NUM — способов много.
А шифрование на уровне клиента через SSL/TLS поддерживается всеми клиентами.
SSL/TLS спасает от MITM при наличие двухстороннего сертификата, сертификаты можно посмотреть в Pidgin (Средства (Tools) -> Сертификаты (Certificates)). Пароль от учетной записи это не проблема при использовании OTP на сервере и наличие другого канала связи (например SMS).
так скажем, чисто для контроллера можно и потерпеть. если конечно Вы настолько неперевариваете синтаксис erlang — то можете написать свой велосипед контроллер на node+crond
LVM для возможность увеличивать тома по ходу (перекачка).
Минимальный размер нужен для того чтобы например ставить этот образ на системы от 15GB Storage — если диска больше — то он автоматически (точнее вручную) будет увеличен за счет LVM до максимального размера физической системы хранения. (имеется в виду диск на которые был проецирован снимок)
Как правило для крупного финансового проекта всегда есть хотя-бы один главный разработчик (Senior Developer) — без этого Вы не сможете проконтролировать правки.
для HP ничего не нужно — там как правило в комплекте идет HP SmartArray как опция h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/index.html по качеству скажу весьма хорошие (правда Gen8 пока не брал, а планирую) — отдельный контроллер ДА — (1) при высоком количестве IOPS дает выйгрыш за счет кэша (2) для защиты в случае потери внешнего питания или отказа одного из дисков. По IBM комплектующим увы не скажу — с ними не работал.
