Solaris: виртуальные срезы / диски для использования с ZFS
Это немного связано с моим предыдущим вопросом. Solaris: Монтирование файловой системы на обработчиках приложения, за исключением того, что этот вопрос предназначен для другой цели и является более простым, так как нет открытия / закрытия / блокировки, это просто блок байтов фиксированной длины с чтением / операции записи.
В любом случае я могу создать виртуальный срез, вроде как RAM-диск или SVM-срез... но я хочу, чтобы чтение и запись проходили через мое приложение.
Я планирую использовать ZFS, чтобы взять несколько виртуальных срезов / дисков и превратить их в один больший для распределенного резервного хранилища со снимками. Мне действительно нравится сжатие и укладка, которые предлагает ZFS. При необходимости я могу гарантировать, что существует только один экземпляр ZFS, обращающийся к этим виртуальным дискам за раз (для предотвращения конфликтов кэша и тому подобного). Если один экземпляр выходит из строя, мы можем убедиться, что он не запустится снова, а затем мы можем запустить другой экземпляр этой ZFS.
Я планирую разместить эти диски по 4 ГБ или около того, затем я могу перемещаться по каждому чанку и решать, где их хранить (конечно же, несколько раз зеркально), а затем иметь доступ к чанам с помощью ZFS и собирать их вместе для увеличения куски для фактического использования. Кроме того, ZFS позволит добавлять эти небольшие фрагменты, если необходимо увеличить размер большего фрагмента.
Я знаю, что было бы дополнительное время ожидания / сетевой трафик, если бы мы использовали мое собственное приложение на Java, но это только для резервного копирования. В производственном хранилище совершенно другая конфигурация, которая не имеет отношения.
Редактировать: у нас есть система, которая использует все доступное пространство, и в основном, когда не хватает места, она удалит старые снимки и увеличит промежутки между старыми снимками. Цель моего предложения - разрешить использование неиспользуемого пространства от производственного оборудования без каких-либо дополнительных затрат. В разное время у разных узлов нашего производственного оборудования будет свободное пространство. Кроме того, система, которую я описываю, должна устранить любую единственную точку отказа при попытке доступа к данным. Я надеюсь, что мне не придется покупать два больших устройства и синхронизировать их. Я бы предпочел просто иметь две точки доступа, и тогда мы можем смешивать большие / маленькие блоки любым удобным для нас способом и легко перемещать данные.
Это перекрестная публикация, потому что это больше связано с программным обеспечением, чем с системным администратором. Оригинальный вопрос здесь: https://serverfault.com/questions/212072. может быть хорошей идеей закрыть оригинал
2 ответа
Кажется, что любой файл фиксированной длины в любой файловой системе подойдет для блочного устройства для использования с ZFS. Не уверен, как работают перезагрузки, но я уверен, что мы можем написать некоторые команды загрузки, чтобы решить это.
Изменить: файл фиксированной длины будет в сетевой файловой системе, такой как NFS.
Одним из способов было бы написать драйвер устройства Solaris, а именно блочное устройство, эмулирующее реальный диск, но вместо этого оно сообщалось бы вашему приложению.
Начните с чтения Учебника по драйверам устройств, а затем посмотрите на исходный код OpenSolaris для реального кода драйверов.
В качестве альтернативы вы можете исследовать изменение цели Solaris iSCSI в качестве интерфейса с вашим приложением. Опять же, просмотр OpenSolaris COMSTAR будет хорошим началом.