БД Vault, что это за файл
Обновлено: 21.11.2024
Когда пользователь Windchill создает информацию, например часть или документ, файлы содержимого могут быть связаны с этим объектом. Используя хранилище файлов, вы можете указать, что для определенного типа объекта в определенном состоянии жизненного цикла файлы содержимого должны храниться в логическом контейнере, называемом хранилищем, в системе вашей сети, а не в базе данных Windchill.
Каждое хранилище файлов содержит папки, соответствующие местам физического хранения (например, каталогам) в хост-системе. В соответствии с установленной вами политикой хранилища загруженный файл сохраняется в расположении файловой системы, представленном хранилищем и папкой, к которой он относится.
Сайт Windchill или кластер – это группа узлов с одним URL-адресом. Доступ к хостам можно получить по отдельности или как единое целое. Хранилища файлов функционируют как элементы сайтов. На следующем рисунке показаны связи между объектами, составляющими сайт.
A — сервер методов Windchill. Сервер методов Windchill, управляющий базой данных Windchill, обрабатывает данные и запросы, которые проходят между базой данных Windchill и внешними хранилищами файлов.
D – Хранилище файлов. Файловая система состоит из нескольких папок. Папки расположены в одном или нескольких хранилищах файлов, которые представляют собой логические конструкции, не связанные с конкретными местоположениями.
H – связь с базой данных. Серверы методов Windchill могут выполнять чтение и запись в базу данных Windchill.
В окне конфигурации хранилища Windchill отображается древовидное представление объекта сайта, которое включает все хосты, хранилища и папки.
Существует несколько преимуществ хранилища файлов, которые следует учитывать при принятии решения о том, как хранить контент:
• Загрузка и скачивание файлов содержимого, которые являются обычными операциями Windchill, выполняются значительно быстрее, если файлы хранятся в хранилище, а не в базе данных.
• Место хранения файлов содержимого прозрачно для пользователя, поэтому никакие пользовательские операции не нужно изменять.
При загрузке очень больших файлов (более 100 МБ) в Windchill не следует загружать в базу данных BLOB-объекты. Хотя это возможно, это может занять значительное время (до нескольких часов для файлов размером более 0,5 ГБ) из-за ограничения скорости записи в BLOB базы данных. Загрузка может перестать работать.
Рекомендуемое решение — настроить Windchill таким образом, чтобы загрузка происходила в хранилища файлов Windchill. Вы можете сделать это одним из двух способов:
• Используйте конфигурацию с несколькими хранилищами и напишите правила, чтобы контент загружался в соответствующие хранилища.
В этой главе описывается дополнительное администрирование, необходимое для реализации хранилища файлов. Конкретные административные задачи и процедуры описаны в интерактивной справке, доступной на соответствующих страницах и в окнах Windchill.
Функция автоматического создания папок позволяет файловому серверу или системному администратору создавать хранилища, которые управляют своими собственными папками, используя пороговое значение, основанное на количестве файлов. Система автоматически создает дисковые папки по мере необходимости в корневой папке. Корневые папки — это папки, которые автоматически управляют своими собственными папками.
При первой регистрации файлового сервера и отсутствии папок в корневой папке первая физическая папка создается автоматически в этой корневой папке.
Эта функция снижает объем работ по обслуживанию для администраторов и позволяет более эффективно использовать пространство, выделенное для файловых хранилищ Windchill.
Ядро секретов базы данных динамически генерирует учетные данные базы данных на основе настроенных ролей. Он работает с рядом различных баз данных через интерфейс плагина. Существует ряд встроенных типов баз данных и открытая платформа для запуска пользовательских типов баз данных для расширения. Это означает, что службам, которым требуется доступ к базе данных, больше не нужно жестко кодировать учетные данные: они могут запрашивать их из Vault и использовать механизм аренды Vault для более удобного обмена ключами. Они называются "динамическими ролями" или "динамическими секретами".
Поскольку каждая служба обращается к базе данных с уникальными учетными данными, аудит значительно упрощается при обнаружении сомнительного доступа к данным. Вы можете отследить его до конкретного экземпляра службы на основе имени пользователя SQL.
Сейф использует собственную внутреннюю систему отзыва, чтобы гарантировать, что пользователи станут недействительными в разумные сроки после истечения срока аренды.
Подсистема секретов базы данных поддерживает концепцию "статических ролей", которые представляют собой сопоставление ролей хранилища с именами пользователей в базе данных "один к одному". Текущий пароль пользователя базы данных сохраняется и автоматически меняется Vault в течение настраиваемого периода времени. Это отличается от динамических секретов, где уникальная пара имени пользователя и пароля создается при каждом запросе учетных данных.Когда для роли запрашиваются учетные данные, Сейф возвращает текущий пароль для настроенного пользователя базы данных, позволяя любому пользователю с соответствующими политиками Сейфа получить доступ к учетной записи пользователя в базе данных.
В настоящее время не все типы баз данных поддерживают статические роли. Обратитесь к документации по конкретной базе данных на левой панели навигации или к таблице ниже в разделе «Возможности базы данных», чтобы узнать, поддерживает ли данная серверная часть базы данных статические роли.
Большинство механизмов секретов должны быть настроены заранее, прежде чем они смогут выполнять свои функции. Эти шаги обычно выполняются оператором или инструментом управления конфигурацией.
Включите механизм секретов базы данных:
По умолчанию механизм секретов включается по имени механизма. Чтобы включить механизм секретов по другому пути, используйте аргумент -path.
Настройте Сейф с правильным подключаемым модулем и информацией о подключении:
Настоятельно рекомендуется создать пользователя в базе данных специально для использования в Сейфе. Этот пользователь будет использоваться для управления динамическими и статическими пользователями в базе данных. В документации этот пользователь называется пользователем root.
Vault будет использовать указанного здесь пользователя для создания/обновления/отзыва учетных данных базы данных. Этот пользователь должен иметь соответствующие разрешения для выполнения действий над другими пользователями базы данных (создание, обновление учетных данных, удаление и т. д.).
Этот механизм секретов может настроить несколько подключений к базе данных. Дополнительные сведения о конкретных параметрах конфигурации см. в документации по конкретной базе данных.
После настройки пользователя root настоятельно рекомендуется сменить пароль этого пользователя, чтобы пользователь хранилища был недоступен ни для кого, кроме самого хранилища:
После этого пароль пользователя, указанный на предыдущем шаге, больше не будет доступен. По этой причине настоятельно рекомендуется создать пользователя специально для Сейфа, чтобы использовать его для управления пользователями базы данных.
Настройте роль, которая сопоставляет имя в Сейфе с набором операторов создания для создания учетных данных базы данных:
Поля > и > будут заполнены подключаемым модулем динамически сгенерированными значениями. В некоторых подключаемых модулях также поддерживается поле >.
После того как модуль секретов настроен и у пользователя/компьютера есть токен Хранилища с соответствующими разрешениями, он может генерировать учетные данные.
Создайте новые учетные данные, прочитав из конечной точки /creds имя роли:
Начиная с Vault 1.6 все базы данных поддерживают динамические и статические роли. Все подключаемые модули, кроме MongoDB Atlas, поддерживают смену учетных данных пользователя root. MongoDB Atlas не поддерживает чередование учетных данных пользователя root, поскольку для аутентификации используется пара открытого и закрытого ключей.
| База данных | Смена корневых учетных данных | Динамические роли | Статические роли | Настройка имени пользователя |
|---|---|---|---|---|
| Cassandra | Да | Да | Да (1.6+) | Да (1.7+) |
| Couchbase | Да | Да | Да | Да (1.7+) |
| Elasticsearch | Да | Да | Да (1.6+) | Да (1.8+) |
| HanaDB | Да (1.6+) | < td>ДаДа (1.6+) | Нет | |
| InfluxDB | Да | Да | Да (1.6+) | Да (1.8+) |
| MongoDB | Да | Да | Да | Да (1.7+) |
| MongoDB Atlas | < td>НетДа | Да | Да (1.8+) | |
| MSSQL | Да | Да | Да | Да (1.7+) |
| MySQL/MariaDB< /td> | Да | Да | Да | Да (1.7+) |
| Oracle | Да | Да | Да | Да (1.7+) |
| PostgreSQL | Да | Да | Да | Да (1.7+) |
| Красное смещение | Да | Да | Да | Да (1.8+) |
| Снежинка | Да | Да | Да | Да (1.8+) | < /tr>