Вам в основном не повезло, если вы как-то не изменили свои требования.
Во-первых, особенно в системах Unix, ничто не мешает нескольким процессам записывать в одни и те же файлы. В ОДНОЙ СИСТЕМЕ это не будет проблемой, у вас просто будет типичное состояние гонки, если две или более записи конфликтуют в одном и том же пространстве файла, в которое будет записана запись. Поскольку он работает в одной системе, он имеет идеальное разрешение на уровне байтов.
Итак, игра с точки зрения наличия нескольких процессов, записывающих в один файл, как эти процессы координируются? Как обеспечить, чтобы они не ходили друг на друга? В Unix, опять же, есть механизм блокировки на основе ОС, который можно использовать для предотвращения этого, но обычно большинство систем реализуют центральный сервер и координируют всю свою запись через эту систему, а затем записывает на диск, одновременно смягчая и обработка любых конфликтов.
Ваша проблема в два раза.
Во-первых, вы предполагаете, что независимые процессы журнала не будут взаимодействовать, что они не будут обмениваться информацией и координировать свои записи с томом. Это бросает гаечный ключ (большой гаечный ключ) прямо на работу.
Во-вторых, вы предлагаете, чтобы не только несколько процессов писали на один и тот же том, но и тот, на который они пишут, был разделен через SAN. Это еще один гаечный ключ.
В отличие от NFS, сети SAN не поддерживают «файловые системы». Скорее они поддерживают «хранение». В основном устройства уровня блока. SAN, как только вы прошли кучу махинаций по управлению томами, на самом деле довольно «глупы» с точки зрения ОС.
Я почти уверен, что на самом деле вы можете смонтировать том на нескольких машинах, но я не уверен, что на устройстве можно больше одного. Для этого есть веские причины.
Проще говоря, SAN - это хранилище на уровне блоков. Блок, скажем, 4K байтов. Это «атомная» единица работы для SAN. Хотите изменить один байт данных? Считайте блок 4K из SAN, измените свой байт и запишите обратно блок 4k.
Если у вас есть несколько машин, считающих, что у них есть «универсальный» доступ к хранилищу SAN, и вы рассматриваете его как файловую систему, значит у вас поврежденная файловая система. Это так просто. Машины напишут, как они думают, как должны выглядеть блоки, в то время как другие машины и разбивают его своей локальной версией. Катастрофа. Руина. Не счастлив.
Даже заставить одну машину писать в SAN, в то время как другая читает с нее, сложно. Это также медленно, так как читатель может сделать несколько предположений о содержимом диска, поэтому ему нужно читать и перечитывать блоки (он не может ничего кэшировать, например, оглавления файловой системы и т. Д., Так как они ' Из-за активности писателя меняем его обратно, поэтому читайте снова ... и снова ...).
Такие вещи, как NFS, «решают» эту проблему, потому что вы больше не работаете с необработанным хранилищем. Скорее вы работаете с реальной файловой системой.
Наконец, нет ничего плохого в том, что независимые файлы журналов транслируются с ваших серверов. Они все еще могут быть запрошены. Вам просто нужно повторить запросы и объединить результаты.
Если у вас есть 5 потоковых машин, и вы хотите «всю активность между 12:00 и 12:05», то сделайте 5 запросов, по одному в каждое хранилище журналов, и объедините результаты. Что касается того, как эффективно запрашивать данные вашего журнала, это проблема индексации, и она не является непреодолимой в зависимости от того, как вы запрашиваете. Если вы запрашиваете время, то создаете файлы по времени (каждую минуту, каждый час и т. Д.) И сканируете их. Если ваша система «редко читается», это не имеет большого значения. Если вам нужна более сложная индексация, вам нужно придумать что-то еще.
Вы можете использовать базу данных для записи файлов и индексов, но я сомневаюсь, что вы найдете многих, кому нравится читать из файлов, которые они не контролируют, или которые меняются под ними.
CouchDB может работать или что-то в этом роде из-за его специфического, устойчивого к сбоям, всегда согласованного формата базы данных.Этот файл данных всегда читается экземпляром базы данных.Это может быть вариант для вас.
Но я все равно буду делать несколько запросов и объединять их.