Варианты хранения для бездисковых серверов
Я пытаюсь построить симуляцию нейронной сети, работающую на нескольких бездисковых экземплярах с высоким процессором. Я планирую использовать постоянный диск для хранения своего кода симуляции и обучающих данных и смонтировать их на всех экземплярах сервера. По сути, это задача сокращения вида карты (несколько узлов работают с одними и теми же данными обучения, результаты всех узлов должны быть собраны в один файл результатов).
Теперь мой единственный вопрос: какие у меня есть варианты (навсегда) сохранить результаты симуляции разных серверов (либо в некоторые моменты во время симуляции, либо один раз в конце). В идеале я хотел бы записать их на один постоянный диск, смонтированный на всех серверах, но это невозможно, потому что я могу монтировать его только для чтения более чем на один сервер.
Какой самый умный (и самый дешевый) способ собрать все результаты моделирования всех серверов обратно на один постоянный диск?
4 ответа
Google Cloud Storage - отличный способ постоянного хранения информации в Google Cloud. Все, что вам нужно сделать, это включить этот продукт для вашего проекта, и вы сможете получить доступ к облачному хранилищу напрямую с ваших виртуальных машин Compute Engine. Если вы создаете свои экземпляры с помощью учетной записи службы 'storage-rw', доступ к ним становится еще проще, поскольку вы можете использовать встроенную в ваши виртуальные машины команду gsutil без необходимости какой-либо явной авторизации.
Чтобы быть более конкретным, перейдите в Google Cloud Console, выберите проект, с которым вы хотите использовать Compute Engine и Cloud Storage, и убедитесь, что обе эти службы включены. Затем используйте область учетной записи службы "storage-rw" при создании виртуальной машины. Если вы используете gcutil для создания своей виртуальной машины, просто добавьте --storage_account_scope=storage-rw (есть также интуитивно понятный способ установки области учетной записи службы, если вы используете Cloud Console для запуска своей виртуальной машины). После того, как ваша виртуальная машина запущена, вы можете свободно использовать команду gsutil, не беспокоясь о выполнении интерактивного входа в систему или шагов OAuth. Вы также можете написать сценарий своего использования, интегрировав любые желаемые запросы gsutil в ваше приложение (gsutil также будет работать в сценарии запуска).
Дополнительную информацию об особенностях учетной записи службы GCE можно найти здесь.
Ответ Марка определенно лучше всего подходит для длительного хранения результатов. В зависимости от ваших требований ввода-вывода и надежности вы также можете настроить один сервер в качестве NFS-сервера и использовать его для удаленного подключения тома на других ваших узлах.
Как правило, сервер NFS будет вашим "главным узлом", и он может обслуживать как двоичные файлы, так и конфигурацию. Рабочие периодически пересматривают каталоги, экспортированные из мастера, чтобы выбрать новые двоичные файлы или конфигурацию. Если вам не нужно много дискового ввода-вывода (вы упомянули нейронное моделирование, поэтому я предполагаю, что набор данных помещается в память, а вы выводите только конечные результаты), может быть достаточно быстро просто записать свой вывод в Каталоги NFS на вашем главном узле, а затем сохраните результаты резервного копирования главного узла в какое-то место, например GCS.
Основным преимуществом использования NFS над GCS является то, что NFS предлагает знакомую семантику файловой системы, которая может помочь, если вы используете стороннее программное обеспечение, которое ожидает считывание файлов с файловых систем. Периодически синхронизировать файлы из GCS в локальное хранилище довольно просто, но требуется запуск дополнительного агента на хосте.
Недостатки настройки NFS состоят в том, что вам, вероятно, нужно синхронизировать UID между хостами, NFS может быть дырой в безопасности (я бы выставлял NFS только в моей частной сети, а не для чего-либо за пределами 10/8) и что для этого потребуется установка дополнительные пакеты на клиенте и сервере для настройки общих ресурсов. Кроме того, NFS будет такой же надежной, как и хост-машина, а хранилище объектов, такое как GCS или S3, будет реализовано с избыточными серверами и, возможно, даже с географическим разнообразием.
Если вы хотите остаться в пространстве продуктов Google, как насчет облачного хранилища Google?
В противном случае, я использовал S3 и Boto для такого рода задач
В качестве более общего варианта вы запрашиваете какое-то общее хранилище объектов. Google, как отмечалось в предыдущих ответах, делает хороший пакет, но почти все облачные провайдеры предоставляют некоторые возможности хранения. Убедитесь, что у вашего облачного провайдера есть оба варианта ключей: хранилище томов, хранилище данных, аналогичное виртуальному диску, и хранилище объектов, хранилище ключей / значений. Оба имеют свои сильные и слабые стороны. Хранилища томов являются заменой виртуальных дисков. Если вы можете использовать stdio, вы можете использовать удаленное хранилище томов. Проблема в том, что они часто имеют структуру диска. Если вы хотите чего-то большего, вы запрашиваете базу данных. Хранилище объектов представляет собой "золотую середину" между диском и базой данных. Это быстро и полуструктурировано.
Я сам пользователь OpenStack - во-первых, потому что он предоставляет и семейства хранилищ, и, во-вторых, он поддерживается различными поставщиками, поэтому, если вы решите перейти от поставщика A к поставщику B, ваш код может остаться неизменным. Вы даже можете запустить его копию на своих компьютерах (см. Www.openstack.org). Обратите внимание, однако, что OpenStack любит память. Вы не собираетесь запускать частное облако на ноутбуке 4 ГБ! Рассмотрим две машины по 16 ГБ.