Integrating Flight Gateway with Signiant Software

Object Mover jobs in Flight Deck and Manager+Agents can integrate with Flight Gateway to accelerate transfers to AWS, Microsoft Azure, or Google Cloud storage.

To integrate Flight Gateway you require:

• a Flight Deck subscription or Manager+Agents version 13.5 or higher
• a license for Flight Gateway (included with Flight Deck)
• a system that meets Flight Gateway requirements

Note: Google Cloud Storage is supported on Flight Deck and Manager+Agents 14.0 or higher.

Cloud Storage Requirements

You must authenticate your cloud storage provider with the Manager to access cloud storage using an Agent. For more information, see Object Storage Profiles.

AWS S3 Storage

Ensure that the user associated with the AWS access key has the following object and bucket operation permissions:

• AbortMultipartUpload
• DeleteObject
• GetObject
• ListBucket
• ListMultipartUploadParts
• PutObject
• GetBucketLocation

Microsoft Azure

Ensure that you have a valid Access Key to grant access to your Blob storage container.

Google Cloud Storage

To configure Google Cloud Storage, you must create a Service Account in the Google Cloud Console. Generate a JSON encoded key to use as a credentials file.

The service account must include account permissions for:

• Storage Object Admin
• Storage Object Creator
• Storage Object Viewer

Enabling Flight Gateway

Once you have installed a gateway on a server and created an endpoint, you must enable Flight Gateway on an Agent.

To configure an Agent for object storage:

1. In the Manager, navigate to Administration > Agent > List.
2. Select an Agent and click Edit.
3. Click to open the Object Storage tab.
4. Click Enable Flight Gateway.
5. Enter the Flight Gateway Server and Port.

6. Click OK to save your changes.

When using Flight Gateway, you must enter your gateway server URL as set in your Flight Administration Console.

Note: The default port for Flight Gateway is 8443. If a different port is required, you must edit the Flight Gateway configuration.

Agent to Gateway Architecture

Connections between Agents and Flight Gateway can be structured in a variety of ways to suit your storage needs.

Basic Architecture

In the most basic configuration, an Agent and Flight Gateway are both installed and configured on the same machine.

All file transfers from the Agent use the local installation of Flight Gateway to connect to the Flight service and use acceleration.

The Agent typically connects to Flight Gateway using localhost port 8443.

Two or More Agents to a Gateway

You can also have two or more Agents, installed on separate machines, connected to a single Flight Gateway. This configuration is typical for networks with a single point of Internet traffic.

All file transfers with a cloud destination sent from an Agent use a Flight Gateway installation to connect to cloud storage.

The Agents connect to Flight Gateway on a separate machine using the server name and port. (e.g. server-name.example.com on port 8443)

Agent to Gateway via Perimeter Network Relay

In most production environments at least one perimeter network or perimeter network is in place. Files transfers must pass through a perimeter network to connect to a cloud storage object. Manager+Agents can use Agents configured as relays to allow transfers to pass through the perimeter network.

The sending Agent must transfer files through a relay to a perimeter Agent. The perimeter Agent uses Flight Gateway, located in the perimeter network, via port 8443 to relay the transfer to cloud storage. In some cases, customers may choose to use the same relay server as the Agent, which is possible with the correct license.

Agents transferring files to cloud storage via the Perimeter Network Relay connect to the Flight Gateway server in the perimeter network. Files sent to cloud storage are first sent to the Perimeter Relay which then routes the job to the Flight service.

Delivering Content to a Peer via S3

When delivering content to a peer or partner from a cloud storage provider there are three different architecture options:

Example scenario: Content kept in an Amazon S3 bucket needs to transfer to a recipient's on-premises storage. The sender and recipient both have a Manager+Agents installation.

Option 1: Sending Through an On-Premises Network

With this option, the content routes via the sender's on-premises network. An accelerated download from the cloud pulls the content to the sender's Agent, and the content is then sent with an accelerated transfer to the recipient's Agent, which can include Relay Agents between the sender and recipient.

Both the sending and receiving Manager applications must establish a trust relationship with each other to allow the file transfer.

For security purposes, the sending Manager has the object storage credentials for their storage object, and the credentials are never shared with the transfer recipient.

Starting the Transfer With Sending Manager

In this case, the sending Manager has the ability to start a job on the receiving Agent's machine, and the receiving Agent controls the transfer.

An ObjectDownloader job schedules with the sending Agent as the source, and the receiving Agent as the target. The content downloads directly to the sending Agent from cloud storage, then sends to the receiving Agent where it saves to disk. While the object storage credentials route through the receiving Agent, they are still encrypted and not accessible.

Starting the Transfer Using Temporary Storage

If the sending Manager cannot start the transfer on the receiving Agent, ObjectDownloader schedules a job with the same source and target Agent, downloads the content from cloud storage, and writes to temporary storage with the sending Agent.

A separate Media Mover job reads the content from the temporary storage and sends the files to the receiving Agent where it saves to disk. Once the transfer completes, the content is automatically removed from the sending Agent's temporary storage.

Option 2: Sharing Credentials

If the receiving Agent has the storage object credentials, the content can transfer directly from the cloud object to the recipient's on-premises storage. An ObjectDownloader job is scheduled on the receiving Manager, and content is automatically downloaded from cloud storage to the receiving Agent, where it is saved to disk.

Note: In this scenario, the sender does not need to have Manager+Agents installed.

Option 3: Using Encrypted Credentials

The sending Manager and receiving Manager establish a trust relationship. An ObjectDownloader job is scheduled on the sending Manager, with the source and target Agent as the receiving Agent.

The receiving Agent authenticates using an encrypted version of the sending Manager's credentials, allowing the receiving Agent to download the content to its storage.