Вопросы и ответы по AWS Storage Gateway

Файловый шлюз Amazon S3 – это конфигурация сервиса шлюза хранилища AWS, которая предоставляет приложениям файловый интерфейс для удобного хранения файлов в виде объектов в Amazon S3 и доступа к ним с помощью стандартных файловых протоколов.

Вот некоторые примеры использования файлового шлюза Amazon S3: а) перенос файловых данных из локального хранилища в Amazon S3 при сохранении быстрого локального доступа к недавно использовавшимся данным; б) резервное копирование файловых данных, находящихся в локальном хранилище (включая базы данных и файлы журналов Microsoft SQL Server и Oracle), в качестве объектов в Amazon S3, чтобы можно было использовать такие возможности S3, как управление жизненным циклом и межрегиональная репликация; в) использование данных, сформированных локальными приложениями, в гибридных облачных процессах для дальнейшей обработки в сервисах AWS с применением машинного обучения, аналитики больших данных или бессерверных функций.

С помощью файлового шлюза Amazon S3 можно переключить свои приложения, устройства и процессы, работающие с файлами, на использование Amazon S3 без какой‑либо модификации. Файловый шлюз Amazon S3 позволяет надежно и безопасно хранить содержимое файлов и сопутствующие метаданные в виде объектов, предоставляя локальным приложениям доступ к кэшированным данным с минимальной задержкой.

Файловый шлюз Amazon S3 поддерживает хранилище Amazon S3 классов Standard, S3 Intelligent‑Tiering, S3 Standard – IA и S3 One Zone – IA. Подробную информацию о классах хранилищ см. в документации по Amazon S3. Необходимо настроить начальный класс хранилища для объектов, которые создает шлюз, после чего файлы из Amazon S3 можно перемещать в Amazon S3 Glacier с помощью политик управления жизненным циклом корзины. Если приложение попытается получить доступ к файлу или объекту, который был сохранен с помощью файлового шлюза Amazon и теперь находится в Amazon S3 Glacier, пользователь получит стандартное сообщение об ошибке ввода‑вывода.

Файловый шлюз Amazon S3 поддерживает клиенты Linux, подключающиеся к шлюзу по протоколу Network File System (NFS) версий 3 и 4.1, а также клиенты Windows, подключающиеся к шлюзу по протоколу Server Message Block (SMB) версий 2 и 3.

Хранилище файлов с общим доступом по NFS или SMB можно создать с помощью Консоли управления AWS или API сервиса. После этого необходимо связать файловое хранилище с новой или существующей корзиной Amazon S3. Чтобы получить доступ к хранилищу из своих приложений, подключите его к приложению с помощью стандартных команд UNIX или Windows. Для удобства в консоли управления показаны строки с примерами команд для всех сред.

Настроить хранилище файлов с общим доступом по NFS можно с помощью административных элементов управления, таких как ограничение доступа для определенных клиентов NFS или сетей, предоставление разрешения только на чтение или на чтение и запись, а также включение функции отмены разрешений пользователя.

Хранилище файлов с общим доступом по SMB можно настроить таким образом, чтобы доступ к нему имели только пользователи Active Directory (AD), или предоставить доступ аутентифицированным гостевым пользователям организации. Можно дополнительно ограничить доступ к хранилищу файлов, предоставив пользователям разрешение только на чтение или на чтение и запись, а также настроив разрешения для определенных пользователей и групп AD.

Да, можно настроить перечисление на основе доступа для общих файловых хранилищ, использующих протокол SMB, чтобы пользователи не могли видеть папки и файлы, для открытия которых у них нет прав. Кроме того, можно контролировать возможность просмотра пользователями общих файловых хранилищ в файловом шлюзе Amazon S3.

Да. Файловый шлюз Amazon S3 интегрирован как с локальной версией Microsoft Active Directory, так и с решениями Active Directory для работы в облаке, например Managed Microsoft AD.

Да. Хранилище файлов с общим доступом по SMB можно экспортировать с использованием имени и пароля гостевого пользователя. Прежде чем настраивать хранилище файлов для гостевого доступа, необходимо изменить пароль по умолчанию в консоли или API сервиса.

Да.

Нет, в настоящий момент метаданные файлов, например сведения о владельце, сохраненные как метаданные объектов S3, нельзя связывать по разным протоколам.

Для доступа к корзине S3 файловый шлюз Amazon S3 использует роль AWS Identity and Access Management (IAM). Роль IAM можно настроить самостоятельно или автоматически через консоль управления шлюза хранилища AWS. При автоматической настройке AWS Storage Gateway создаст в аккаунте пользователя новую роль IAM и свяжет ее с политикой доступа IAM, разрешающей доступ к корзине S3. Роль и политика доступа IAM создаются в рамках аккаунта, поэтому их можно изменять их по своему усмотрению.

Чтобы использовать хранилище файлов с общим доступом, подключите его к приложению с помощью стандартных команд UNIX или Windows. Для удобства в Консоли управления показаны строки с примерами команд.

Файловое хранилище может быть привязано к корню корзины S3 или к префиксу S3 в корзине S3. Если во время создания файлового хранилища вы укажете префикс S3, то привяжете к нему хранилище. Если вы не создадите префикс S3 во время создания файлового хранилища, то хранилище будет привязано к корню корзины S3.

Да. Имя файлового хранилища не обязательно должно совпадать с именем корзины или префикса S3.

Да. Имя файлового хранилища можно изменить.

Файлы хранятся в виде объектов в корзинах S3. Для объектов, создаваемых файловым шлюзом, можно настроить начальный класс хранилища. Между файлами и объектами существует взаимно‑однозначное соответствие. При этом можно настроить начальный класс хранилища для создаваемых шлюзом файлов Amazon S3.

Ключ объекта является производной пути к файлу в файловой системе. Например, если шлюз имеет имя хоста file.amazon.com и связан с корзиной my-bucket/my-prefix, файловый шлюз откроет точку подключения file.amazon.com:/export/my-bucket/my-prefix. При локальном подключении по адресу /mnt/my-bucket/my-prefix и создании файла с именем file.html в каталоге /mnt/my-bucket/dir/my-prefix этот файл будет сохранен как объект в корзине my‑bucket с ключом my-prefix/dir/file.html. Создание разреженных файлов приведет к созданию в S3 неразреженного объекта с нулевым заполнением.

Клиенты могут создавать, читать, обновлять и удалять файлы и каталоги. Кроме того, они могут изменять разрешения, а также указывать других владельцев файлов и папок. В Amazon S3 файлы сохраняются в виде отдельных объектов. В S3 каталоги представлены в виде объектов папок, и ими можно управлять, используя синтаксис консоли S3. Символические и жесткие ссылки не поддерживаются. Попытка создать ссылку приводит к ошибке. При выполнении общих операций с файлами изменяются метаданные файла, что приводит к удалению текущего объекта S3 и созданию нового объекта S3.

Клиентам операции переименования будут казаться атомарными, но S3 не поддерживает переименование объектов. При переименовании файла или каталога шлюз выполняет запросы COPY и PUT для создания копии объектов в S3 с новыми ключами, а затем удаляет исходные объекты. Это позволяет избежать повторной отправки больших файлов по сети. Переименование каталогов, содержащих большое количество файлов, выполняется не мгновенно, поэтому до завершения операции переименования в S3 хранятся две копии данных, а операции в каталогах заблокированы.

Клиенты могут получать доступ к метаданным в формате POSIX, в том числе к сведениям о владельце, разрешениям и отметкам времени, которые надежно хранятся в пользовательских метаданных объектов S3, связанных с файлами. При создании хранилища файлов с общим доступом в существующей корзине сохраненные метаданные восстанавливаются, и клиент может получить к ним доступ.

Для каждого файлового хранилища можно включить определение MIME‑типов загруженных объектов при создании или активировать эту функцию позднее. При включении этой возможности файловый шлюз будет определять MIME‑тип файла по его расширению, а затем соответствующим образом устанавливать значение Content‑Type для объектов S3. Это может пригодиться при использовании файлового шлюза для управления объектами в S3, доступ к которым осуществляется напрямую по URL‑адресу или которые распространяются через Amazon CloudFront.

Да. После загрузки объектов в хранилище S3 с ними можно работать в облаке AWS без обращения к файловому шлюзу Amazon S3. Объекты наследуют свойства корзины, в которой они хранятся, такие как управление жизненным циклом и межрегиональная репликация.

Управлять объектами, доступ к которым осуществляется через файловое хранилище совместного доступа, должен только шлюз. Если перезаписать или обновить напрямую объект, который был добавлен через файловый шлюз Amazon S3, при обращении к этому объекту через хранилище совместного доступа может возникнуть ошибка.

Если во время настройки корзины для использования через файловый шлюз Amazon S3 в ней уже содержатся какие‑либо объекты, они будут представлены клиентам при обращении по NFS и SMB в виде файлов с использованием объектных ключей. Файлам будут назначены метаданные по умолчанию.

Для уменьшения задержки и количества запросов к Amazon S3 файловый шлюз Amazon S3 сканирует заголовки на предмет связанных с объектами метаданных только в случае явного указания списка требуемых файлов или каталогов. В ходе этого сканирования собираются метаданные файлов, а содержимое самих файлов загружается только после завершения чтения объекта.

Шлюз не выполняет автоматическую загрузку всех объектов или данных, находящихся в корзине. Данные загружаются только при явном запросе со стороны клиентов. Кроме того, для дополнительного уменьшения количества передаваемых данных файловый шлюз использует многокомпонентные загрузки и хранение копий, поэтому в S3 загружаются только измененные данные.

Для объектов, загруженных непосредственно в корзину S3, т. е. без использования файлового шлюза и хранилища NFS, можно настроить сведения о владельце и разрешения по умолчанию.

Для объектов, загруженных непосредственно в корзину S3, т. е. без использования файлового шлюза Amazon S3 и хранилища SMB, метаданные, такие как сведения о владельце и разрешения, наследуются от родительской папки объекта. Разрешения в корневом каталоге хранилища являются неизменными, и объекты, созданные непосредственно в корневой папке, наследуют эти разрешения. См. документацию по настройкам метаданных объектов, созданных за пределами шлюза.

К одному файловому шлюзу могут подключаться несколько клиентов. Однако, как и в случае с другими NFS‑серверами, одновременное изменение объектов несколькими клиентами может привести к непредсказуемым результатам. Для безопасного одновременного доступа процесс должен регулироваться на уровне приложения.

Нет. Рекомендуется использовать одну программу для записи данных. Если перезаписать или обновить напрямую объект, который был добавлен через файловый шлюз, при обращении к этому объекту через хранилище совместного доступа может возникнуть ошибка. Одновременное изменение одного объекта (например, через API сервиса S3 и файловый шлюз Amazon S3) может привести к непредсказуемым результатам, поэтому рекомендуется избегать таких настроек.

Настраивать несколько шлюзов для записи в одну корзину не рекомендуется, поскольку это может привести к непредсказуемым результатам. Чтобы избежать конфликтов, можно принудительно включить уникальные имена объектов или префиксы в рабочий процесс приложения. S3 File Gateway будет выдавать оповещения о работоспособности, когда в такой конфигурации будут происходить ошибки.

Да. Файлы из одной корзины, управляемые файловым шлюзом Amazon S3, можно читать через несколько клиентов. Можно предоставить права только на чтение из файлового хранилища совместного доступа и разрешить нескольким шлюзам читать объекты из одной корзины. Кроме того, с помощью консоли шлюза хранилища, периодического автоматического процесса обновления кэша или API RefreshCache можно обновлять перечень известных шлюзу объектов.

Обратите внимание: если к общему хранилищу файлов не настроить доступ только на чтение, файловый шлюз Amazon S3 не будет отслеживать или ограничивать непреднамеренную запись файлов в эту корзину через другие шлюзы. Поэтому ограничение на запись из нескольких источников должно быть установлено на уровне приложения.

Да, мониторинг файловых хранилищ с общим доступом можно выполнять с использованием метрик Amazon CloudWatch и получать уведомления об окончании операций с файлами через CloudWatch Events. Подробнее см. в разделе Monitoring your File Share.

При записи файлов в общее файловое хранилище с помощью файлового шлюза Amazon S3 данные сначала сохраняются локально, а потом асинхронно загружаются в корзину S3. Настроить оповещения о завершении загрузки отдельного файла можно с помощью Событий AWS CloudWatch. Такие оповещения можно использовать для запуска дополнительных рабочих процессов, выполнение которых связано с загруженными в S3 данными, например для вызова функций AWS Lambda или Amazon EC2 Systems Manager Automation. Подробнее см. в документации по оповещениям о загрузке файла.

Оповещение о загрузке файла содержит оповещение для каждого отдельного файла, который загружается в Amazon S3 через файловый шлюз S3. Оповещения о событиях S3 содержат оповещения о частичной загрузке файлов, поэтому по оповещению о событии S3 невозможно определить, завершена ли загрузка файла.

При записи файлов в общее файловое хранилище с помощью файлового шлюза Amazon S3 данные сначала сохраняются локально, а потом асинхронно загружаются в корзину S3. С помощью Событий Amazon CloudWatch можно настроить оповещения о завершении загрузки рабочего набора файлов. Такие оповещения можно использовать для запуска дополнительных рабочих процессов, выполнение которых связано с загруженными в S3 данными, например для вызова функций AWS Lambda или Amazon EC2 Systems Manager Automation. Подробнее см. в документации по оповещениям о загрузке рабочего набора файлов.

Да. С помощью консоли, процесса обновления кэша, вызванного файловой системой, или вызова API RefreshCache можно обновить перечень известных файловому шлюзу объектов Amazon S3. Когда работа API RefreshCache будет завершена, вы получите оповещение от Событий AWS CloudWatch. С помощью этих оповещений можно отправлять электронные письма, используя Amazon Simple Notification Service (SNS), или запускать локальные процессы обработки с использованием обновленного контента. Подробнее см. в документации.

Да, шлюз можно использовать для доступа к корзинам, принадлежащим другим аккаунтам. Подробнее см. в документации об использовании файлового хранилища для доступа к нескольким аккаунтам.

Да, при создании файлового хранилища можно установить доступ к корзинам S3 с настройкой Requester Pays. Плата, связанная с доступом к данным в корзинах этого типа, будет возложена на инициатора запроса.

Вы можете создать несколько файловых хранилищ для одной корзины S3, указав префикс S3 во время создания хранилища.

Для одного шлюза можно создать до 50 хранилищ на корзину S3. Мы не ограничиваем количество файловых хранилищ на корзину в разных шлюзах, но в каждом шлюзе их может быть не более 50. При этом рекомендуется использовать для записи данных в корзину одну программу: файловый шлюз Amazon S3 либо клиента, имеющего непосредственный доступ к S3.

Да. Изменить имя файлового хранилища можно.

Максимальный размер файла – 5 ТБ (совпадает с максимально допустимым размером одного объекта в сервисе S3). При попытке записать файл размером более 5 ТБ выводится сообщение об ошибке «file too large», загружаются только первые 5 ТБ данных.

Шлюз возвращает значение 8 ЭБ как общий объем хранилища пользователя. В сервисе Amazon S3 общий объем хранилища не ограничен.

Да. Политики управления жизненным циклом и межрегиональной репликацией, а также оповещения о событиях S3, настроенные для корзины, напрямую применяются к объектам, загруженным в корзину через шлюз AWS Storage Gateway.

Можно использовать политики управления жизненным циклом S3 для изменения уровня хранения объекта, а также для удаления старых объектов или их версий. Когда политика жизненного цикла удаляет объекты, необходимо включить функцию периодического обновления кэша или вызвать API RefreshCache, чтобы отобразить эти изменения для клиентов NFS.

При использовании корзины S3, которая является целевой для межрегиональной репликации, может потребоваться включить функцию периодического обновления кэша или совершить вызов API RefreshCache, чтобы синхронизировать кэш шлюза и корзину S3.

При использовании оповещений о событиях S3 можно получать события для частичных файлов, созданных шлюзом, чтобы обеспечить надежное хранение данных в S3. Частичные файлы могут возникать по нескольким причинам, например вследствие необходимости освободить пространство в кэше шлюза или из‑за большого количества операций записи в файл. Эти частичные файлы могут быть не согласованы с приложением.

Файловый шлюз Amazon S3 поддерживает протокол SMB версий 2 и 3, а также протокол NFS версий 3, 4.0 и 4.1. Мы продолжаем тестировать распространенные приложения для резервного копирования. Сообщите нам через AWS Support или сотрудников AWS, отвечающих за поддержку вашего аккаунта, если требуется поддержка определенного приложения.

Нет. Файловый шлюз Amazon S3 позволяет хранить файлы в виде объектов в S3.

Файловый шлюз Amazon S3 следует использовать, если требуется доступ к объектам S3 в виде файлов с помощью стандартных операций файловой системы. Кроме того, файловый шлюз Amazon S3 обеспечивает быстрый доступ к локальному хранилищу и эффективную передачу данных. Если приложению не требуется выполнять операции файловой системы и файлы можно загружать напрямую, используйте API S3.

Локальное дисковое хранилище шлюза используется для временного хранения изменившихся данных, которые требуется переместить в AWS. Кроме того, оно используется для локального кэширования данных, к которым необходимо обеспечить доступ для чтения с низкой задержкой. Файловый шлюз автоматически управляет кэшем, сохраняя самые последние использованные данные, которые определяются на основе операций чтения и записи клиента. Данные удаляются из кэша только в том случае, если требуется пространство для сохранения более новых данных.

Чтобы максимально повысить эффективность записи, шлюз использует механизм отложенной записи, при котором данные сначала сохраняются на диск, а потом асинхронно загружаются в хранилище S3. Для максимальной эффективности операций чтения шлюз использует данные из локального кэша. Если необходимые данные отсутствуют в кэше, они синхронно подгружаются из хранилища Amazon S3 с помощью запросов GET на уровне байтов.

Размер локального кэша, как правило, должен соответствовать рабочему набору данных, к которому необходимо обеспечить быстрый доступ. Если размер кэша недостаточен, это приведет к увеличению задержки при операциях чтения, поскольку необходимые данные надо будет загружать из хранилища S3. При этом операции записи могут вовсе закончиться неудачей, поскольку в кэше будет недостаточно места для локального сохранения данных перед выгрузкой в S3.

Выделять кэш необходимо на основании следующих параметров.
1. Размер набора данных, к которым требуется доступ с минимальной задержкой, чтобы можно было снизить задержку чтения путем снижения частоты запросов к данным от S3.
2. Размер файлов, которые записываются на шлюз приложениями пользователя.

Если размер кэша недостаточен и свободного места для локального хранения данных в ожидании загрузки на S3 не остается, это может привести к снижению производительности и ошибкам при записи. Подробнее о мониторинге использования кэша см. в разделе документации Monitoring Your File Share.

Данные, записанные в кэш приложениями пользователя или путем извлечения из Amazon S3, удаляются из кэша только в том случае, если требуется пространство для сохранения более новых данных.

Нет. Каждому файлу без каких‑либо изменений назначается прямое соответствие объекту в корзине. Это позволяет работать с данными напрямую в S3 без использования шлюза или дополнительных приложений для восстановления.

Файловый шлюз Amazon S3 использует многокомпонентные загрузки и операции COPY и PUT, поэтому в S3 загружаются только измененные данные, что уменьшает количество передаваемых данных. Шлюз не выполняет автоматическую загрузку всех объектов или данных, находящихся в корзине. Данные загружаются только при явном запросе со стороны NFS-клиента.

Даже если корзина настроена на использование S3 Transfer Acceleration, файловый шлюз не будет использовать адреса ускоренных серверов.

При передаче данных между шлюзом и хранилищем AWS они шифруются с использованием SSL. По умолчанию данные, хранящиеся в S3, шифруются на стороне сервера с помощью ключей шифрования Amazon S3 Managed Encryption Keys (SSE‑S3). Для каждого файлового хранилища можно настроить шифрование объектов с помощью ключей под управлением AWS KMS, используя шифрование на стороне сервера в KMS. Важные сведения об использовании этой функции см. в разделе Encrypting Your Data Using AWS Key Management System (Шифрование данных с использованием системы управления ключами AWS) руководства пользователя шлюза хранилища.  

Файловый шлюз Amazon FSx оптимизирует локальный доступ к файловым хранилищам Windows на Amazon FSx, упрощая доступ пользователей к данным FSx for Windows File Server с низкой задержкой и при сохранении пропускной способности хранилища. Пользователи получают преимущества локального кэша с часто используемыми данными, к которым они могут обращаться, что обеспечивает повышение производительности и сокращает трафик передачи данных. Операции над файловой системой, такие как чтение и запись файлов, выполняются в локальном кэше, а файловый шлюз Amazon FSx синхронизирует кэшированные данные с FSx for Windows File Server в фоновом режиме. Имея такие возможности, вы можете объединить все данные из локальных хранилищ файлов в AWS on FSx for Windows File Server и пользоваться преимуществами защищенных, надежных и полностью управляемых файловых систем.

Многие локальные приложения для рабочего стола чувствительны к задержке, и прямой доступ к файлам в AWS из удаленных точек может стать причиной задержек у конечных пользователей и приводить к снижению производительности. Кроме того, если большое количество пользователей получит прямой доступ к данным в облаке может привести к перегруженности общих ресурсов, влияющих на пропускную способность, таких как ссылки AWS Direct Connect. Amazon FSx File Gateway позволяет использовать для таких рабочих нагрузок Amazon FSx for Windows File Server и помогает заменить локальное хранилище полностью управляемым, масштабируемым и очень надежным файловым хранилищем в AWS, не затрагивая приложения или сеть.

Amazon FSx File Gateway предоставляет сервер файлового протокола SMB для клиентов, а также локальный кэш с часто используемыми данными, к которым они могут обращаться с такой же низкой задержкой, которой они могли бы ожидать в AWS. Операции над файловой системой, такие как чтение и запись файлов, выполняются в локальном кэше, а файловый шлюз Amazon FSx синхронизирует кэшированные данные с Amazon FSx for Windows File Server в фоновом режиме. Также Amazon FSx File Gateway помогает свести к минимуму количество передаваемых данных, оптимизируя использование пропускной способности сети с AWS.

Чтобы использовать файловый шлюз Amazon FSx, вам необходима по крайней мере одна рабочая файловая система Amazon FSx и локальный доступ к Amazon FSx for Windows File Server либо через VPN, либо через подключение AWS Direct Connect. Чтобы начать работу с FSx для Windows File Server, просмотрите инструкции в документации по ссылке. Затем вы можете начать либо с загрузки и развертывания виртуального устройства VMware для Amazon FSx File Gateway, либо аппаратного устройства AWS Storage Gateway в локальной среде. После того как будет установлен файловый шлюз Amazon FSx и вы получите доступ к FSx for Windows File Server, вы сможете пользоваться Консолью управления AWS для подключения файловой системы FSx for Windows File Server. Затем Консоль управления AWS проведет вас через все шаги, которые необходимо совершить для открытия локального доступа к файловым хранилищам.

После настройки файловых хранилищ клиентские системы смогут находить в файловом шлюзе Amazon FSx файловые хранилища, которые соответствуют выбранным файловым системам Amazon FSx, и подключаться к ним. Когда файловые хранилища подключены, пользователи могут читать и записывать файлы локально, пользуясь всеми функциями FSx для Windows File Server. 

Файловый шлюз Amazon FSx можно использовать для доступа к файловым системам Windows во всех регионах AWS, где предлагается FSx for Windows File Server.

Плата за использование файлового шлюза Amazon FSx взимается почасово. Информацию о ценах см. на странице цен на шлюз хранилища AWS.

Файловый шлюз Amazon FSx поддерживает версии 2.x и 3.x протокола Server Message Block (SMB). SMB поддерживается Microsoft Windows, MacOS и Linux.

Файловый шлюз Amazon FSx связывает локальные хранилища файлов и их содержимое с файловыми хранилищами, которые хранятся удаленно в Amazon FSx for Windows File Server. Соотношение между удаленными и локально видимыми файлами и их хранилищами составляет 1:1.

Да. Вы можете получать доступ к файловым хранилищам как из файлового шлюза Amazon FSx, так и непосредственно из Amazon FSx в AWS. Однако в один и тот же момент не следует записывать файлы из разных источников. В этом выпуске файловый шлюз Amazon FSx не предотвращает одновременную запись из нескольких источников, что приводит к конфликтам.

Вы можете управлять Amazon FSx for Windows File Server через удаленный интерфейс управления с использованием всех инструментов, которые предоставляет FSx for Windows File Server.

Да. Вам разрешено подключать шлюз к хранилищам, в которых находится до 5 файловых систем, если они входят в один и тот же домен Active Directory. Файловый шлюз Amazon FSx подключает только один домен Active Directory.

Можно выполнить развертывание виртуальной машины с программным обеспечением файлового шлюза Amazon FSx на VMware ESXi, Microsoft Hyper‑V или Linux KVM либо развертывание шлюза хранилища в виде аппаратного устройства.

Файловый шлюз Amazon FSx становится участником домена Active Directory, если инфраструктура AD находится в AWS Directory Service или если она расположена локально. Когда файловый шлюз Amazon FSx является участником домена, он имеет доступ ко всем пользователям и политикам, установленным для этого домена, с целью повысить безопасность. Затем файловый шлюз Amazon FSx будет вести себя, как любой сервер Windows, и применять все применимые политики доступа к файлам в зависимости от настроек Active Directory. 

Файловый шлюз Amazon FSx использует встроенные средства контроля доступа Windows. Он совместим с любыми существующими статическими списками доступа, которые работают с Microsoft Windows. Максимальный размер ACL составляет 64 КБ или примерно 1820 записей контроля доступа. Это идентично хостам Windows Server. Средства контроля доступа устанавливаются и хранятся на FSx Windows File Server, поэтому вам нужно создать их только один раз, и они будут отражены во всех подключенных файловых шлюзах.

Да. Файловый шлюз Amazon FSx поддерживает шифрование SMB до новейшей спецификации SMB версии 3.1.1, включая AES 128 CCM и AES 128 GCM. Совместимые клиенты будут автоматически подключаться с использованием шифрования. Кроме того, файловый шлюз Amazon FSx использует шифрование SMB при обмене данными с FSx for Windows File Server в AWS. Вам необходимо настроить либо VPN, либо ссылку Direct Connect на AWS, а также установить соответствующие политики для разрешения трафика SMB и управляющего трафика через AWS.

Подобно файловому шлюзу Amazon S3, файловый шлюз Amazon FSx непрерывно проверяет работоспособность шлюза VMware. Результаты этой проверки также доступны для сервиса мониторинга VMware. В случае программного, аппаратного или сетевого сбоя VMware заново запускает шлюз на новом или текущем хосте, если он в рабочем состоянии. Во время повторного запуска максимальное время простоя может составлять до 60 секунд. После перезапуска все подключения к шлюзу автоматически восстанавливаются без необходимости ручной настройки. При повторной инициализации шлюз отправит метрики в облако с данными о доступности события. Таким образом, клиенты будут видеть полную картину происходящего. 

Встроенный в файловый шлюз Amazon FSx сервис VMware HA и мониторинг приложений отслеживают сбои гипервизора, а также аппаратные, сетевые и программные ошибки, которые вызывают задержки и приводят к потере доступа к хранилищу файлов. 

Файловый шлюз Amazon FSx поддерживает до 50 хранилищ и 500 активных сеансов клиентов, подключенных к инстансам файлового шлюза Amazon FSx в одной конфигурации инстанса.

Для клиентов сервиса обеспечивается сохранность данных на уровне 99,999999999 %, регулярные проверки исправности со стороны AWS, шифрование данных, получение точных и правильных данных при восстановлении, а также сокращение расходов (по сравнению с хранением физических лент во вторичных хранилищах) в случае хранения виртуальных лент на AWS с использованием ленточного шлюза в сочетании с S3 Glacier Deep Archive. Во‑первых, все виртуальные ленты, хранимые в S3 Glacier Deep Archive, реплицируются и сохраняются как минимум в трех географически распределенных зонах доступности с уровнем надежности 99,999999999 %. Во‑вторых, AWS регулярно проводит проверки исправности, чтобы гарантировать возможность считывания данных и отсутствие в них ошибок. В‑третьих, все хранимые в S3 Glacier Deep Archive ленты защищены шифрованием S3 на стороне сервера с использованием ключей по умолчанию или клиентских ключей KMS. Клиенты также избавляются от риска физической порчи или кражи данных, связанных с перемещением лент. В‑четвертых, ленточный шлюз гарантирует получение верных данных в случае их восстановления – в отличие от вторичных хранилищ, в которых есть шанс получить при восстановлении некорректные данные или поврежденную ленту. И наконец, хранение данных в S3 Glacier Deep Archive позволяет сократить ежемесячные расходы на хранение по сравнению с использованием вторичных хранилищ.

Ленточный шлюз поддерживает хранилища следующих классов: S3 Standard, S3 Glacier и S3 Glacier Deep Archive. Когда приложение для резервного копирования записывает данные на ленты, эти данные сохраняются на виртуальных лентах в виртуальной ленточной библиотеке Amazon S3. После того как ленты извлекаются из приложения, они сохраняются в архивном хранилище S3 Glacier или S3 Glacier Deep Archive.

На ленточном шлюзе можно создавать виртуальные магнитные ленты емкостью от 100 ГиБ до 15 ТиБ. Обратите внимание, что плата взимается за объем сохраненных данных на каждой ленте, а не за общий размер ленты.

Один ленточный шлюз может содержать в виртуальной ленточной библиотеке до 1500 виртуальных лент суммарной емкостью до 1 ПБ. Ограничения на общее количество архивируемых данных или виртуальных лент отсутствуют. С целью масштабирования хранилища для виртуальных лент, не находящихся в архиве, можно развертывать дополнительные ленточные шлюзы. Подробнее см. в документации по лимитам шлюза хранилища.

Количество лент, хранящихся в архиве, и их размер не ограничены.

Виртуальные магнитные ленты, сохраненные в архивах S3 Glacier или S3 Glacier Deep Archive, можно извлекать в хранилище S3. Лента, находящаяся в архиве S3 Glacier, извлекается в хранилище S3 с использованием стандартной процедуры. Ее продолжительность составляет, как правило, 3–5 часов. Лента, находящаяся в архиве S3 Glacier Deep Archive, извлекается в хранилище S3 с использованием стандартной процедуры. Ее продолжительность составляет, как правило, 12 часов.

Перед тем как начать работу с виртуальной лентой, содержащей ваши данные, ее необходимо сохранить в виртуальной ленточной библиотеке. Доступ к данным в виртуальной ленточной библиотеке осуществляется мгновенно. Если виртуальная лента с данными находится в архиве, ее можно извлечь оттуда с помощью Консоли управления AWS или API. Для этого нужно выбрать виртуальную ленту, а затем виртуальную ленточную библиотеку, в которую требуется загрузить эту ленту. Ленту, находящуюся в архиве S3 Glacier и S3 Glacier Deep Archive, можно извлечь в хранилище S3 в течение 3–5 часов и 12 часов, соответственно. После того как виртуальная лента станет доступна в виртуальной ленточной библиотеке, данные с виртуальной ленты можно будет восстановить с помощью приложения для резервного копирования.

Нет. Доступ к данным на виртуальных лентах с помощью API сервисов Amazon S3 и Amazon S3 Glacier не предусмотрен. Однако с помощью API ленточного шлюза можно управлять виртуальной ленточной библиотекой или виртуальной ленточной полкой.

При создании новых лент с помощью консоли Storage Gateway или API в качестве целевого архивного хранилища можно указать S3 Glacier Deep Archive. Когда ПО для резервного копирования будет создавать новые ленты, они будут помещаться в архив в S3 Glacier Deep Archive. Виртуальную магнитную ленту, находящуюся в архиве S3 Glacier Deep Archive, можно извлечь в хранилище S3 с использованием стандартной процедуры, продолжительность которой составляет, как правило, 12 часов.

Да. Ленточный шлюз поддерживает перенос лент из S3 Glacier в S3 Glacier Deep Archive. Связать ленту, размещенную в пуле Glacier, с пулом Deep Archive можно с помощью консоли или API AWS Storage Gateway. После этого ленточный шлюз перенесет виртуальную ленту в пул Deep Archive, связанный с классом хранилища S3 Glacier Deep Archive. За перенос ленты из S3 Glacier в S3 Glacier Deep Archive начисляется плата. Если перенос ленты в S3 Glacier Deep Archive выполняется до истечения 90 дней, дополнительно начисляется плата за досрочное удаление из S3 Glacier.

Нет, ленту из S3 Glacier Deep Archive нельзя перенести в S3 Glacier. Можно извлечь ленту из S3 Glacier Deep Archive в S3 или удалить ее из S3 Glacier Deep Archive.

Интерфейс виртуальной ленточной библиотеки можно использовать в приложениях для резервного копирования и архивации, поддерживающих стандартный интерфейс ленточных библиотек на основе iSCSI. Полный список поддерживаемых приложений для резервного копирования см. на странице с обзором шлюза хранилища.

При передаче данных между шлюзом и хранилищем AWS они шифруются с использованием SSL. По умолчанию данные, сохраненные ленточным шлюзом в хранилище S3, шифруются на стороне сервера с помощью ключей шифрования под управлением Amazon S3 (SSE‑S3).

Дополнительно можно настроить шифрование на лентах с помощью ключей, управляемых AWS KMS, посредством API сервиса Storage Gateway. Можно задать в качестве ключа KMS один из управляемых главных ключей клиента (CMK). Настроенный CMK, использованный для шифрования ленты, нельзя изменять после создания. Важные сведения об использовании этой функции см. в разделе Encrypting Your Data Using AWS Key Management System (Шифрование данных с использованием системы управления ключами AWS) руководства пользователя шлюза хранилища.

Каждый шлюз томов поддерживает до 32 томов. В режиме кэширования каждый том может иметь размер до 32 ТБ, а общий размер шлюза может достигать 1 ПБ (32 тома по 32 ТБ каждый). В режиме хранения каждый том может иметь размер до 16 ТБ, а общий размер шлюза может достигать 512 ТБ (32 тома по 16 ТБ каждый). Подробнее см. в документации по лимитам шлюза хранилища.

Шлюзы томов сжимают данные для передачи и хранения в AWS. Это позволяет снизить расходы на передачу и хранение данных. Хранилище для томов не выделяется заранее, поэтому оплате подлежит только объем сохраненных данных тома, а не его общая емкость.

Тома пользователя хранятся в корзине Amazon S3, поддерживаемой сервисом AWS Storage Gateway. Доступ к томам можно получить с помощью операций ввода‑вывода через AWS Storage Gateway. Прямой доступ с использованием действий API сервиса Amazon S3 не поддерживается. Можно делать снимки состояния томов шлюза на момент времени, которые становятся доступны в виде снимков состояния Amazon EBS и могут быть преобразованы в тома Storage Gateway или тома EBS. С помощью файлового шлюза с данными можно работать непосредственно в S3.

При передаче данных между шлюзом и хранилищем AWS они шифруются с использованием SSL. По умолчанию данные, сохраненные шлюзом томов в S3, шифруются на стороне сервера с помощью ключей шифрования под управлением Amazon S3 (SSE‑S3).

Дополнительно можно настроить шифрование для данных, хранимых в томах AWS, с использованием управляемых ключей AWS KMS посредством API сервиса Storage Gateway. Можно будет задать в качестве ключа KMS один из главных ключей клиента (CMK). Настроенный CMK, использованный для шифрования тома, нельзя изменять после создания. Важные сведения об использовании этой функции см. в разделе Encrypting Your Data Using AWS Key Management System (Шифрование данных с использованием системы управления ключами AWS) руководства пользователя шлюза хранилища.

Да. Создать снимок состояния EBS из тома AWS, зашифрованного с помощью KMS, можно посредством API. Снимок состояния EBS будет зашифрован с использованием того же ключа, который применялся для шифрования тома.

Да. Создать зашифрованный том из снимка состояния EBS, зашифрованного с помощью KMS, можно посредством API. Для зашифрованного тома может использоваться тот же ключ, который использовался для шифрования снимка состояния EBS. Как вариант, можно указать для тома другой ключ шифрования.

Вы можете делать снимки состояния томов со шлюзом тома в виде снимков состояния Amazon EBS. Можно также использовать снимок состояния тома в качестве отправной точки для создания нового тома Amazon EBS, который затем можно подключить к инстансу Amazon EC2. Это позволяет легко создать зеркальную копию данных локальных приложений для приложений, работающих в Amazon EC2, при необходимости увеличения объема вычислительных ресурсов по требованию или на случай аварийного восстановления.

Для кэшируемых томов, данные которых уже хранятся в Amazon S3, снимки состояния можно использовать для сохранения определенных версий данных. Такой подход позволяет при необходимости возвратиться к предыдущей версии или создать новый том на основе определенной версии. Снимки состояния можно создавать по расписанию или в произвольный момент времени. При создании нового снимка состояния сохраняются только те данные, которые были изменены с момента сохранения последнего снимка. Если объем тома составляет 100 ГБ, но только 5 ГБ данных были изменены с момента создания последнего снимка состояния, то только эти дополнительные 5 ГБ данных снимка состояния будут храниться в Amazon S3. При удалении снимка состояния будут удалены только те данные, которые не нужны для других снимков состояния.

Для томов, хранящихся на шлюзе, где данные тома хранятся локально, снимки состояния обеспечивают надежное удаленное хранение резервных копий в Amazon S3. При необходимости восстановления такой том можно создать из снимка состояния. Можно также использовать снимок состояния тома, хранящегося на шлюзе, в качестве отправной точки для нового тома Amazon EBS, который затем можно подключить к инстансу Amazon EC2.

Снимок состояния представляет собой копию тома на момент запроса на создание данного снимка. Снимок состояния содержит всю информацию, имеющуюся на момент его создания и требуемую для восстановления данных в новый том. В снимок состояния будут включены данные, записанные вашим приложением в том перед созданием снимка, но еще не загруженные в AWS.

Снимок сразу же получит идентификатор и будет виден в Консоли управления AWS и через интерфейс командной строки AWS, но сначала будет находиться в статусе PENDING. Как только все данные, записанные в том перед запросом на создание снимка состояния, будут загружены из шлюза в EBS, статус изменится на AVAILABLE. После этого можно использовать данный снимок для создания нового шлюза или тома EBS.

Каждый снимок состояния получает уникальный идентификатор. Его можно посмотреть в Консоли управления AWS. Указав идентификатор, можно создать том AWS Storage Gateway или Amazon EBS на основе любого из имеющихся снимков состояния.

С помощью Консоли управления AWS можно создать новый том виртуального шлюза из снимка состояния, сохраненного в Amazon S3. а затем подключить его как устройство iSCSI к локальному серверу приложений.

Поскольку основные данные кэшируемых томов хранятся в хранилище Amazon S3, при создании нового тома из снимка состояния шлюз сохраняет данные снимка в Amazon S3, и они становятся основными данными нового тома.

Поскольку первичные данные сохраненных томов хранятся локально, при создании нового тома из снимка состояния шлюз загружает содержащиеся в снимке состояния данные на локальный носитель. После этого они становятся основными данными нового тома.

Нет, процесс создания снимков состояния не требует отключения томов и не влияет на работу приложений. Однако следует учесть, что снимок состояния включает только записанные в том Amazon Storage Gateway данные, поэтому в него могут не войти данные, сохраненные в локальном кэше приложения или ОС.

Да. Для каждого из томов можно создавать снимки состояния по графику. Вы можете установить определенное время при ежедневном создании снимков либо интервал создания (каждый час, каждые 2, 4, 8, 12 или 24 часа).

Время, требуемое для создания снимка состояния, зависит от размера тома и скорости интернет‑подключения к AWS. AWS Storage Gateway выполняет сжатие всех данных перед их загрузкой, что позволяет сократить время создания снимка состояния.

Нет, доступ к снимкам состояния есть только из сервисов AWS Storage Gateway и Amazon EBS, и с ними нельзя работать напрямую с помощью API Amazon S3.

Ограничения на количество снимков состояния или объем данных для выполнения снимков отсутствуют.

Использование AWS Backup для резервного копирования томов, созданных шлюзом томов, упрощает процессы резервного копирования данных и обеспечивает централизованное управление ими. Это снижает операционную нагрузку и позволяет достичь соответствия требованиям по всему спектру используемых ресурсов AWS. AWS Backup позволяет создавать настраиваемые политики резервного копирования по расписанию в соответствии с актуальными требованиями. С помощью AWS Backup можно создавать правила резервного копирования, хранения данных и истечения срока хранения, которые избавляют от необходимости разработки собственных скриптов или ручного резервного копирования томов шлюза. И наконец, сервис позволяет централизованно осуществлять управление процессами резервного копирования и соответствующий мониторинг для всех используемых шлюзов томов, а также других ресурсов AWS (например, томов EBS и баз данных RDS).

AWS Backup позволяет создавать однократные резервные копии данных или настраивать расписание резервного копирования томов для шлюза томов. Созданные резервные копии томов хранятся в корзинах Amazon S3 в виде снимков Amazon EBS и доступны для просмотра в консоли AWS Backup или Amazon EBS. Копии томов, созданные Резервным копированием AWS, можно удалить в консоли этого сервиса вручную или автоматически.

Для управления процессами резервного копирования необходимо войти в консоль Storage Gateway или в консоль AWS Backup. Начав работу в консоли Storage Gateway, можно перейти в консоль AWS Backup для завершения настройки плана резервного копирования или запуска резервного копирования по требованию. Из консоли AWS Backup, в свою очередь, можно настроить план резервного копирования или запустить резервное копирование томов шлюза по требованию.

Нет. Все существующие возможности снимков состояния шлюза томов и сами снимки Amazon EBS останутся доступными без каких‑либо изменений. Консоль Storage Gateway по‑прежнему можно будет использовать для создания томов из снимков EBS, а консоль Amazon EBS – для просмотра и удаления существующих снимков.

Да. Существующие возможности шлюза томов по‑прежнему можно использовать для создания снимков состояния Amazon EBS, а сделанные ранее снимки состояния – для восстановления томов. Расписание резервного копирования сервиса AWS Backup действует независимо от расписания создания снимков состояния шлюза томов и предоставляет дополнительный инструмент для централизованного управления политиками резервного копирования и хранения данных.

Да. AWS Backup создаст резервную копию тома, зашифрованного KMS, используя ключ, который был задействован для шифрования самого тома.

AWS Backup поддерживает резервное копирование томов шлюза томов в том же регионе, в котором работает AWS Backup.

Шлюз хранилища AWS доступен в виде аппаратного устройства с утвержденной конфигурацией сервера, на которое заранее установлено программное обеспечение шлюза хранилища. Управление таким устройством осуществляется через Консоль AWS.

Аппаратное устройство поддерживает файловый шлюз Amazon S3 с интерфейсами NFS и SMB, файловый шлюз Amazon FSx с SMB, шлюз томов с кэшируемыми томами и интерфейсом iSCSI, а также ленточный шлюз с интерфейсом iSCSI‑VTL.

Аппаратное устройство облегчает развертывание локального шлюза хранилища AWS и управление им в таких ИТ‑средах, как удаленные офисы и отделы, в которых отсутствует инфраструктура виртуального сервера, нет достаточных дисковых ресурсов и ресурсов памяти или отсутствует персонал с навыками управления гипервизором. Это избавляет от необходимости приобретать дополнительную инфраструктуру, которая требуется для функционирования локальной виртуальной машины Storage Gateway в виртуальной среде.

Есть две модели с 5 ТБ или 12 ТБ локального кэша SSD.

Аппаратное устройство основано на проверенных конфигурациях серверов. Технические характеристики представлены на странице продукта Аппаратное устройство шлюза хранилища.

Аппаратное устройство поддерживается в 16 регионах AWS, включая «Восток США (Северная Виргиния, Огайо)», «Запад США (Северная Калифорния, Орегон)», «Канада (Центральная)», «Южная Америка (Сан-Паулу)», «Европа (Ирландия, Франкфурт, Лондон, Париж, Стокгольм)» и «Азия и Тихий океан (Мумбаи, Сеул, Сингапур, Сидней, Токио)».

Настройте IP‑адрес через локальную аппаратную консоль устройства и введите его в консоли шлюза хранилища AWS для активации устройства. При этом аппаратное устройство будет связано с аккаунтом AWS. После активации аппаратного устройства вы создаете желаемый тип шлюза для запуска на аппаратном устройстве. Затем шлюз выбранного типа будет включен на устройстве. Вы управляете аппаратным устройством Storage Gateway и используете его из Консоли AWS так же, как и в случае с виртуальным устройством. Дополнительную информацию см. в документации по аппаратному устройству.

Нет. Аппаратное устройство поддерживает запуск только одного шлюза.

Да. Чтобы изменить тип шлюза после его установки на аппаратном устройстве, выберите Remove Gateway (Удалить шлюз) в консоли шлюза хранилища. Шлюз и все связанные с ним ресурсы будут удалены. После этого на аппаратном устройстве можно будет запустить новый шлюз.

В модели емкостью 5 ТБ можно расширить хранилище, чтобы увеличить полезную емкость локального кэша до 12 ТБ, добавив к устройству пять дополнительных SSD-накопителей. Если аппаратное устройство уже активировано и привязано к аккаунту AWS, перед расширением хранилища нужно выполнить его сброс до заводских настроек.

Нет. Добавляйте только те SSD, которые поставляет производитель устройства. Эти SSD-накопители одобрены для использования в аппаратном устройстве Storage Gateway.

Да. Аппаратное устройство использует программный RAID-массив ZFS и обеспечивает защиту от сбоев накопителей хранилища. Модель на 5 ТБ выдерживает отказ одного SSD-накопителя, а модель на 12 ТБ – отказ до двух SSD-накопителей.

Storage Gateway непрерывно проверяет работоспособность шлюза. Результаты этой проверки также доступны для сервиса мониторинга VMware. В случае программного, аппаратного или сетевого сбоя VMware заново запускает шлюз на новом или текущем хосте, если он в рабочем состоянии. Во время повторного запуска максимальное время простоя может составлять до 60 секунд. После перезапуска все подключения к шлюзу автоматически восстанавливаются без необходимости ручной настройки. При повторной инициализации шлюз отправит метрики в облако с данными о доступности события. Таким образом, клиенты будут видеть полную картину происходящего.

Сервис высокой доступности Storage Gateway можно настроить в кластерных средах VMware vSphere, которые поддерживают VMware HA и используют общее хранилище томов.

За использование Storage Gateway с интегрированным сервисом высокой доступности отдельная плата не взимается.

Встроенный в Storage Gateway сервис VMware HA и мониторинг приложений отслеживают сбои гипервизора, а также аппаратные, сетевые и программные ошибки, которые вызывают задержки и приводят к потере доступа к общему хранилищу, томам или виртуальной ленточной библиотеке. Кроме того, они отвечают за их восстановление.

Да.

Во время перезапуска шлюза клиенты NFS могут испытывать задержки до 60 секунд во время чтения или записи при подключении к файловым шлюзам. После такой задержки будет попытка повторного подключения, если использовались рекомендованные настройки монтирования. Клиенты SMB могут заблокировать чтение или запись файла во время перезапуска, в зависимости от настроек клиента. Во время перезапуска шлюза все процессы чтения и записи iSCSI для шлюза томов и ленточного шлюза будут приостановлены, а затем автоматически попытаются снова восстановиться.

Да. Шлюзы возобновят работу и будут использовать то же основное общее хранилище с теми же очередями загрузки и локальным кэшем.

Нет. Шлюзы возобновят работу и будут использовать то же основное общее хранилище с теми же очередями загрузки и локальным кэшем.

Если шлюз развернут в среде VMware с активированной функцией VMware HA, вы сможете настроить параметры перезапуска Storage Gateway VM в центре управления VMware vSphere. С помощью состояния работоспособности Storage Gateway VM можно настроить автоматический перезапуск шлюза в определенный тайм-аут.

VMware HA отслеживает работу основной инфраструктуры: хранилище и сеть. Storage Gateway проверяет работоспособность файловой системы, доступность адресов SMB и NFS, а также проводит мониторинг важных процессов в шлюзе, чтобы обеспечить непрерывную доступность не только основной инфраструктуры, но и всего сервиса для ваших пользователей и приложений.

Да. Использование высокой доступности Storage Gateway в облаке VMware не требует каких-либо дополнительных изменений. Функция VMware HA по умолчанию доступна в VMware Cloud on AWS. Также поддерживаются общие тома.

Во время настройки нового шлюза для VMware вы можете протестировать HA. Также можно проверить, поддерживает ли развернутый шлюз режим HA. Для этого в консоли выберите пункт Test VMware HA.

Во время перезапуска шлюза в консоли AWS Storage Gateway отображаются события доступности в таблицах журналов и прерывания в графиках производительности.

Да. Если вы настроили CloudWatch, то события доступности, запущенные при повторном подключении шлюза, будут отображаться в CloudWatch.

Если вы настроили CloudWatch, событие CloudWatch будет отображаться при повторном запуске. Кроме того, в графиках производительности появятся метрики о работоспособности шлюза, включая несколько активных сеансов.

Да. Администраторы могут настроить тайм‑аут в консоли vSphere, который перезапустит сервис, если шлюз не доступен в течение указанного периода (в секундах).

При передаче данных между любым устройством шлюза и хранилищем AWS они шифруются с использованием SSL. По умолчанию данные, сохраненные сервисом AWS Storage Gateway в S3, шифруются на стороне сервера с помощью ключей шифрования под управлением Amazon S3 (SSE‑S3). При необходимости можно настроить различные типы шлюзов для шифрования сохраненных данных с помощью AWS Key Management Service (KMS) через API сервиса Storage Gateway. Ниже приведена подробная информация о поддержке KMS файловым шлюзом, ленточным шлюзом и шлюзом томов.

Да. AWS Storage Gateway соответствует требованиям HIPAA. При наличии договора делового партнерства (BAA) с AWS можно использовать шлюз хранилища для хранения, резервного копирования и архивирования закрытой медицинской информации (PHI) в масштабируемых, экономичных и надежных сервисах хранения AWS (в том числе в Amazon S3, Amazon S3 Glacier, глубоком архиве Amazon S3 Glacier, Amazon FSx для Windows File Server и Amazon EBS, которые также соответствуют требованиям HIPAA).

Информацию о сервисах AWS, соответствующих требованиям HIPAA, можно найти на странице Соответствие требованиям HIPAA. Там же можно заключить договор BAA с AWS. Соответствие требованиям HIPAA для Storage Gateway относится ко всем типам шлюзов (файловым шлюзам, шлюзам томов и ленточным шлюзам).

Ответ: Да, согласно последним оценкам, AWS Storage Gateway соответствует требованиям стандарта безопасности данных индустрии платежных карт (PCI DSS). Существующие клиенты могут загрузить отчеты по аттестату соответствия требованиям (AOC) и обзору сферы ответственности PCI в Консоли управления AWS с помощью AWS Artifact. Потенциальные клиенты могут запросить эти отчеты в процессе работы со службой продаж AWS.

Да, AWS Storage Gateway соответствует требованиям FedRAMP High с высоким уровнем авторизации в регионах AWS GovCloud (США) и средним уровнем авторизации в коммерческих регионах AWS (США). Дополнительные сведения доступны на странице соответствия требованиям AWS FedRAMP.

Файловый шлюз S3, файловый шлюз Amazon FSx, шлюз томов и ленточный шлюз поддерживают адреса, совместимые с FIPS 140-2.

AWS Storage Gateway поддерживает адреса, совместимые с FIPS 140-2, в таких регионах AWS: Восток США (Сев. Вирджиния), Восток США (Огайо), Запад США (Сев. Калифорния), Запад США (Орегон), Канада (Центр) GovCloud (Запад США) и GovCloud (Восток США).

Список адресов, проверенных на соответствие требованиям стандарта FIPS и доступных в шлюзе хранилища AWS, см. в Справочном руководстве по адресам шлюза хранилища AWS или в Руководстве пользователя AWS GovCloud (США).

Нет, сервис AWS Storage Gateway Hardware Appliance не соответствует требованиям стандарта FIPS 140-2.

Да, журналы аудита файлового шлюза можно использовать для отслеживания клиентских операций с папками и файлами в рамках файловых SMB‑хранилищ совместного доступа.

Вы можете настроить журналы аудита файлового шлюза для отслеживания пользовательских операций с папками и файлами на уровне хранилища совместного доступа для каждого общего SMB‑хранилища.

Журналы аудита файлового шлюза поддерживают файловые SMB‑хранилища совместного доступа.

Вы увидите подробную информацию о следующих зарегистрированных операциях с файлами и каталогами: открытие, удаление, чтение, запись, переименование, изменение разрешений и успешность выполнения файловых операций. Для каждой операции также записывается информация о пользователе, в том числе метка времени, домен Active Directory, имя пользователя и IP‑адрес клиента.

Получить доступ к журналам аудита файлового шлюза можно в Amazon CloudWatch. При желании журналы аудита можно также отправить из CloudWatch в корзину Amazon S3. Журналы аудита можно просматривать из Amazon S3 с помощью Amazon Athena, а также экспортировать их в сторонние приложения обеспечения безопасности информации и управления событиями (SIEM) для проведения анализа в этих инструментах.

Да, при создании новых виртуальных лент вручную или с использованием конфигурации автоматического создания ленты на ленточном шлюзе можно выбрать тип ленты WORM. Данные на виртуальных лентах WORM нельзя удалить намеренно или случайно из приложения резервного копирования. Кроме того, функция блокировки хранения ленты в ленточном шлюзе предотвращает удаление заархивированных виртуальных лент на фиксированный период времени или даже на неограниченный срок.

Да. Можно воспользоваться сервисом AWS Direct Connect, чтобы дополнительно повысить пропускную способность и снизить затраты на использование сети путем установки выделенного сетевого подключения между локальным шлюзом и облаком AWS. Обратите внимание, что сервис AWS Storage Gateway эффективно использует полосу пропускания, ускоряя загрузку данных локальных приложений в AWS.

Да. Шлюзы томов и ленточных накопителей поддерживают конфигурацию прокси‑серверов Socket Secure версии 5 (SOCKS5) между локальным шлюзом и AWS. Файловые шлюзы поддерживают конфигурацию прокси‑сервера HTTP (HyperText Transfer Protocol).

Да. Развертывание Storage Gateway можно выполнить в частной немаршрутизируемой сети, если эта сеть подключена к облаку Amazon VPC через DX или VPN. Трафик Storage Gateway будет перенаправлен через адреса VPC, работающие на основе AWS PrivateLink – технологии, которая обеспечивает частное соединение между сервисами AWS за счет использования в VPC эластичных сетевых интерфейсов (ENI) с частными IP‑адресами. Подробнее о PrivateLink рассказывается в документации по PrivateLink. Чтобы настроить AWS PrivateLink для шлюза хранилища, обратитесь к документации AWS PrivateLink для шлюза хранилища.

Да, этот сервис поддерживает PrivateLink для всех типов шлюзов (файлового шлюза, шлюза томов и ленточного шлюза).

Оплата начисляется за каждый час, в течение которого адрес VPC endpoint оставался выделенным. Дополнительно начисляется плата за обработку данных за каждый гигабайт, переданный через VPC endpoint, независимо от источника или адресата трафика.

Шлюзы с поддержкой PrivateLink можно активировать через Консоль AWS, если используемый веб‑браузер имеет доступ как к Интернету, так и к частной сети, или через интерфейс командной строки в регионе, где находятся эти шлюзы.

Чтобы использовать файловый шлюз локально с PrivateLink и частными виртуальными интерфейсами (VIF) для доступа к корзинам Amazon S3, необходимо настроить прокси‑сервер на базе Amazon EC2. Для получения доступа к Amazon S3 через частную сеть необходимо использовать адреса шлюза S3, а эти адреса не доступны из локальных сред напрямую. Прокси‑сервер будет предоставлять доступ к S3 через адрес VPC, благодаря чему сервис станет доступен для локального файлового шлюза. Рекомендуется использовать семейство инстансов EC2, оптимизированное для передачи данных по сети.

Нет.

Шлюзы томов и ленточные шлюзы подключаются напрямую к сервисам AWS через VPC endpoint для Storage Gateway и не требуют прокси‑сервера для S3.

Для правильной работы сетевые интерфейсы аппаратного устройства должны иметь возможность взаимодействовать с общедоступными адресами AWS. Однако для виртуальных интерфейсов виртуальных машин шлюза можно настроить использование PrivateLink и обмен данными только с адресами VPC.

Шлюз AWS Storage Gateway является посредником между приложениями и сервисами хранилищ Amazon. Скорость работы зависит от платформы, используемой для запуска программного обеспечения Storage Gateway (аппаратное устройство, виртуальная машина, инстанс Amazon EC2), и ряда других факторов. К таким факторам относятся пропускная способность сети между инициатором iSCSI или NFS-клиентом и шлюзом, скорость работы и конфигурация локальных дисков, конфигурация виртуальной машины, объем локального хранилища, выделенный для шлюза, а также пропускная способность сети между шлюзом и хранилищем Amazon. Инструкции по оптимизации среды шлюза хранилища AWS для повышения производительности см. в технической документации AWS.

Сведения о запуске AWS Storage Gateway на виртуальной машине или инстансе Amazon EC2 см. в разделе требований руководства пользователя AWS Storage Gateway. Шлюз хранилища AWS также предлагается как аппаратное устройство с проверенными техническими характеристиками.

Шлюз томов и ленточный шлюз обеспечивают сжатие данных как при передаче, так и при хранении, позволяя снизить расходы на передачу и хранение данных. Сервис загружает только изменившиеся данные, сводя к минимуму объем данных, пересылаемых через Интернет.

Да, можно ограничить пропускную способность сети, используемую шлюзом для синхронизации данных с AWS, на основе расписания для шлюзов томов и ленточных шлюзов. Можно задать день недели, время и пропускную способность для входящего и исходящего трафика.

С помощью сервиса Amazon CloudWatch можно отслеживать метрики и предупреждения о производительности шлюза, которые предоставляют данные о хранилище, пропускной способности, скорости передачи данных и задержке. Эти метрики и предупреждения доступны непосредственно в CloudWatch; также можно воспользоваться ссылками в консоли AWS Storage Gateway, которые приводят к метрикам и предупреждениям CloudWatch для рассматриваемого ресурса. Подробнее см. на странице сведений о продукте и ценах на CloudWatch.

Можно использовать метрики Amazon CloudWatch, включая CachePercentDirty, CacheHitPercent, CacheFree и CachePercentUsed. Их можно посмотреть, перейдя по ссылке «Monitoring» на вкладке сведений о шлюзе в консоли AWS Storage Gateway.

Можно использовать метрики Amazon CloudWatch, включая CloudBytesUploaded и CloudBytesDownloaded.

Рекомендуемые предупреждения Amazon CloudWatch можно создавать при создании нового шлюза или после создания нового шлюза с помощью консоли шлюза хранилища AWS. Предупреждения для шлюза также можно создавать на консоли Amazon CloudWatch.

AWS Storage Gateway периодически устанавливает важные обновления и исправления ПО на виртуальной машине шлюза. Можно настроить еженедельное обслуживание, которое позволит управлять временем установки обновлений на шлюзе. Можно также вручную устанавливать обновления, когда они становятся доступными, с помощью консоли шлюза хранилища AWS либо API. Процесс обновления обычно занимает всего несколько минут. Дополнительную информацию см. в разделе Managing Gateway Updates (Управление обновлениями шлюза) нашей документации.

При начислении платы учитываются три аспекта: объем хранилища, количество запросов и количество передаваемых данных. Подробнее см. на странице цен на шлюз хранилища AWS.

Файловый шлюз хранит данные непосредственно в Amazon S3. Плата начисляется по тарифам Amazon S3 за объем, занимаемый объектами, и количество запросов, выполняемых файловым шлюзом. Подробную информацию см. на странице цен на Amazon S3.

Плата начисляется за объем данных в томах и на виртуальных лентах, хранимых в AWS. Это плата пропорциональна количеству дней использования и зависит от региона. Оплате подлежит только фактически используемый объем томов или виртуальных лент, а не выделенный объем хранилища. Все данные, хранимые в томе или на виртуальной ленте, сжимаются на шлюзе перед передачей в AWS. Это позволяет сократить расходы на хранение данных. Подробнее см. на странице цен на шлюз хранилища AWS.

Снимки состояния EBS для томов шлюза хранятся в Amazon EBS. Плата начисляется в соответствии с тарифами Amazon EBS. Для снижения затрат при создании нового снимка состояния сохраняются только те данные, которые были изменены с момента сохранения последнего снимка. Подробную информацию см. на странице цен на Amazon EBS.

Если шлюз записывает данные в AWS, за это будет взиматься плата по тарифу 0,01 USD за гигабайт данных, но не более 125 USD в месяц за каждый шлюз. Плата за чтение данных из AWS не взимается. Поскольку шлюз выполняет кэширование данных, оптимизирует пропускную способность, а в случае ленточного шлюза и шлюза томов еще и сжимает данные, объем данных, записанных в AWS, может быть меньше объема данных, записанных приложением в шлюз. Объем данных, записанных шлюзом в AWS, можно отслеживать с помощью метрик Amazon CloudWatch. Кроме того, для сокращения расходов можно настроить ограничение пропускной способности на шлюзе.

За извлечение виртуальной ленты, находящейся в архиве S3 Glacier, начисляется плата по тарифу 0,01 USD за гигабайт хранимых на ленте данных. Например, при извлечении 5 лент, на каждой из которых хранится 100 ГБ, будет начислена плата 5 х 100 ГБ х 0,01 USD = 5,00 USD.

Если виртуальная лента удаляется в течение трех месяцев с момента помещения в архив S3 Glacier, или шести месяцев с момента помещения в архив S3 Glacier Deep Archive, начисляется плата за досрочное удаление. В случае если виртуальная лента более трех месяцев хранится в архиве S3 Glacier или более шести месяцев – в архиве S3 Glacier Deep Archive, плата за удаление не начисляется.

В регионе Восток США (Сев. Вирджиния) для архивов, удаленных в течение первых трех месяцев, предусмотрена пропорциональная плата в размере 0,012 USD за гигабайт. Например, если удалить одну виртуальную ленту объемом 1 ГБ через месяц после ее передачи в архив S3 Glacier, будет начислена плата в размере 0,008 USD за досрочное удаление. Если ту же самую ленту удалить через два месяца после ее загрузки, за досрочное удаление будет начислено 0,004 USD.

За хранение виртуальных лент в S3 Glacier Deep Archive начисляется плата по тарифам класса хранилища S3 Glacier Deep Archive. Подробные сведения о ценах на ленточный шлюз см. на странице цен на шлюз хранилища.

Объем использования и стоимость виртуальных лент, хранящихся в пуле Deep Archive, отображаются в ежемесячном счете AWS отдельной позицией в разделе AWS Storage Gateway Deep Archive; они отделены от расходов на AWS Storage Gateway. Однако если вы используете инструмент управления затратами на AWS, объем использования и стоимость виртуальных лент, хранящихся в пуле Deep Archive, включаются в ежемесячные отчеты о расходах в раздел AWS Storage Gateway, а не выносятся в отдельную позицию.

Для региона AWS Восток США (Сев. Вирджиния) перенос виртуальной ленты из архива S3 Glacier в S3 Glacier Deep Archive оплачивается по тарифу 0,032 USD за 1 ГБ хранящихся на ленте данных. Например, плата за перенос ленты размером 100 ГБ из архива S3 Glacier в S3 Glacier Deep Archive составит 100 ГБ x 0,032 USD/ГБ = 3,2 USD. При переносе ленты из архива S3 Glacier в S3 Glacier Deep Archive до истечения 90 дней дополнительно начисляется плата за досрочное удаление ленты из S3 Glacier.

Плата начисляется за передачу каждого гигабайта данных через Интернет в направлении от AWS к виртуальному шлюзу. Передача данных при загрузке в AWS не оплачивается.

В консоли Billing and Cost Management отображается расчетная сумма за пользование каждым из сервисов, включая тома и виртуальные магнитные ленты AWS Storage Gateway, с начала месяца до текущей даты. Для анализа уровня использования по отдельным томам или виртуальным лентам воспользуйтесь подробными финансовыми отчетами, чтобы посмотреть ежедневный уровень использования каждого ресурса.

Плата начисляется за запросы в S3, сделанные файловым шлюзом от имени пользователя, для хранения и извлечения файлов из S3 в виде объектов. Шлюз кэширует данные в объеме, который соответствует объему выделенных локальных дисков, что помогает снизить затраты на извлечение данных.

При настройке журналов аудита файлового шлюза взимается плата по стандартным тарифам для Amazon CloudWatch Logs, Amazon CloudWatch Events и Amazon CloudWatch Metrics.

Система выставления счетов работает по всемирному скоординированному времени (UTC). Календарный месяц начинается в полночь по UTC первого дня каждого месяца.

Если не указано иное, представленные здесь цены не включают применимые налоги и сборы, в том числе НДС и применимый налог с продаж. Для клиентов с адресом выставления счета в Японии использование региона Азия и Тихий океан (Токио) облагается потребительским налогом Японии.

Да, услуга AWS Premium Support распространяется на решение вопросов, связанных с использованием сервиса AWS Storage Gateway. Подробную информацию и цены см. на странице сведений о Поддержке AWS-премиум.

Обширная база знаний сообщества AWS доступна на форуме обсуждения шлюза хранилища AWS.

Свяжитесь со службой поддержки AWS, которая обеспечивает поддержку программного обеспечения и сервиса шлюза хранилища AWS. При решении проблем, связанных с оборудованием, AWS Support сотрудничает со службой поддержки его производителя. Рекомендуется приобрести услугу Поддержка AWS-премиум.

Сервисный код для аппаратного устройства можно найти на вкладке Hardware консоли AWS Storage Gateway.

AWS Support сотрудничает с производителем оборудования для оказания поддержки. Поддержка оборудования входит в комплект покупки устройства и включает круглосуточную поддержку по телефону в течение 36 месяцев, а также обслуживание на месте для замены деталей с прибытием специалиста на следующий рабочий день.

Аппаратное устройство поставляется с трехлетней гарантией от производителя оборудования, которая предусматривает обслуживание на месте для замены деталей с прибытием специалиста на следующий рабочий день. Информацию о гарантии можно найти здесь.