This chapter describes the deployment processes specific to the Core. It includes the following sections:

Although not actually a deployment process, a SteelFusion Core running software version 4.3 or later has a dashboard that, when the Core is initially deployed, provides widgets that direct the administrator to key configuration tasks such as the ones covered in the following sections. Therefore, it is very easy to see at a glance which deployment tasks have not yet been completed. Widgets are provided for adding an Edge, adding a failover peer, adding a storage array, and adding LUNs. Once configuration is complete, the dashboard provides a graphical view of SteelFusion-related activity (cache efficiency, Edge read/write performance), status reports (Core alarms, HA health), and storage (LUN capacity, backend storage performance).

For details on the Core dashboard, see the SteelFusion Core Management Console User’s Guide.

Complete the following tasks:

This section describes a typical port configuration. You might require additional routing configuration depending on your deployment scenario.

This section includes the following topics:

The following table summarizes the ports that connect the Core appliance to your network. Unless noted, the port and descriptions are for all Core models: 2000, 3000, and 3500.

Figure: Core Ports for Core models 2000 and 3000 shows a basic HA deployment indicating some of the SFCR 2000 and 3000 ports and use of straight-through or crossover cables. You can use the same deployment and interface connections for the 3500, but the interface names are different.

For more information about HA deployments, see SteelFusion Appliance High-Availability Deployment.

You configure interface routing by choosing Configure > Networking: Management Interfaces from the Core Management Console.

This section describes the following scenarios:

In this scenario, you do not need additional routes.

The following table shows a sample configuration in which each interface has an IP address on a separate subnet.

If all interfaces are in the same subnet, only the primary interface has a route added by default. You must configure routing for the additional interfaces.

The following table shows a sample configuration.

You can also perform this configuration using the ip route CLI command. For details, see the SteelFusion Command-Line Interface Reference Manual.

If a subset of interfaces, excluding primary, are in the same subnet, you must configure additional routes for those interfaces.

The following table shows a sample configuration.

You can also perform this configuration using the ip route CLI command. For details, see the SteelFusion Command-Line Interface Reference Manual.

If some but not all interfaces, including primary, are in the same subnet, you must configure additional routes for those interfaces.

The following table shows a sample configuration.

You can also perform this configuration using the ip route CLI command. For details, see the SteelFusion Command-Line Interface Reference Manual.

If your network infrastructure supports jumbo frames, configure the connection between the Core and the storage system as described in this section. Depending on how you configure Core, you might configure the primary interface or one or more data interfaces.

In addition to configuring Core for jumbo frames, you must configure the storage system and any switches, routers, or other network devices between Core and the storage system.

To configure jumbo frames on you storage array, see the documentation from your storage array vendor.

The iSCSI initiator settings dictate how the Core communicates with one or more storage arrays through the specified portal configuration.

iSCSI configuration includes:

CHAP functionality and MPIO functionality are described separately in this document. For more information, see Using CHAP to secure iSCSI connectivity and Use CHAP.

In the Core Management Console, you can view and configure the iSCSI initiator, local interfaces for MPIO, portals, and targets by choosing Configure > Storage: iSCSI, Initiators, MPIO. For more information, see the SteelFusion Core Management Console User’s Guide.

In the Core CLI, use the following commands to access and manage iSCSI initiator settings:

This section includes the following topics:

Before you can configure LUNs in Core, you must provision the LUNs on the storage array and configure the iSCSI initiator. For more information, see Provisioning LUNs on the storage array and Configuring the iSCSI initiator.

You expose LUNs by scanning for LUNs on the storage array, and then mapping them to the Edges. After exposing LUNs, you can further configure them for failover, MPIO, snapshots, and pinning and prepopulation.

In the Core Management Console, you can expose and configure LUNs by choosing Configure > Manage: LUNs. For more information, see the SteelFusion Core Management Console User’s Guide.

In the Core CLI, you can expose and configure LUNs with the following commands:

For more information, see the SteelFusion Command-Line Interface Reference Manual.

Granite 2.6 introduced the LUN expansion feature. Prior to Granite 2.6, to resize a LUN you needed to unmap the LUN from an Edge, remove the LUN from Core, change the size on the storage array, add it back to Core, and map it to the Edge.

The LUN expansion feature generally automatically detects LUN size increases made on a data center storage array if there are active read and write operations, and then propagates the change to the Edge. However, if there are no active read and write operations, you must perform a LUN rescan on the Core Configure > Manage: LUNs page for the Core to detect the new LUN size.

If the LUN is pinned, you need to make sure the blockstore on its Edge can accommodate the new size of the LUN.

The process of configuring Fibre Channel LUNs for Core requires configuration in both the ESXi server and the Core.

For more information, see SteelFusion and Fibre Channel and the Fibre Channel on SteelFusion Core Virtual Edition Solution Guide.

This section describes the process to remove a LUN from a Core configuration. This process requires actions on both the Core and the server running at the branch.

The MPIO feature enables you to configure multiple physical I/O paths (interfaces) for redundant connectivity with the local network, storage system, and iSCSI initiator.

Both Core and Edge offer MPIO functionality. However, these features are independent of each other and do not affect each other.

The MPIO feature enables you to connect Core to the network and to the storage system through multiple physical I/O paths. Redundant connections help prevent loss of connectivity in the event of an interface, switch, cable, or other physical failure.

You can configure MPIO at the following separate and independent points:

You can configure MPIO interfaces through the Core Management Console or the Core CLI.

In the Core Management Console, choose Configure > Storage Array: iSCSI, Initiator, MPIO. Configure MPIO using the following controls:

For details about configuring MPIO interfaces in the Core Management Console, see the SteelFusion Core Management Console User’s Guide.

In the Core CLI, open the configuration terminal mode and run the following commands:

These commands require additional parameters to identify the LUN. For details about configuring MPIO interfaces in the Core CLI, see the SteelFusion Command-Line Interface Reference Manual.

This section describes Core pool management. It includes the following topics:

Core Pool Management simplifies the administration of large installations in which you need to deploy several Cores. Pool management enables you to manage storage configuration and check storage-related reports on all the Cores from a single Management Console.

Pool management is especially relevant to Core-v deployments when LUNs are provided over Fibre Channel. VMware ESX has a limitation for raw device mapping (RDM) LUNs, which limits Core-v to 60 LUNs. In releases prior to SteelFusion 3.0, to manage 300 LUNs, you needed to deploy five separate
Core-vs. To ease the Core management in SteelFusion 3.0 and later, you can combine Cores into management pools.

In SteelFusion 3.0 and later, you can enable access to the SteelHead REST API framework. This access enables you to generate a REST API access code for use in SteelFusion Core pool management. You can access the REST API by choosing Configure > Pool Management: REST API Access.

For more information about pool management, see SteelFusion Core Management Console User’s Guide.

Pool management is a two-tier architecture that allows each Core to become either manager or a member of a pool. A Core can be part of only one pool. The pool is a single-level hierarchy with a flat structure, in which all members of the pool except the manager have equal priority and cannot themselves be managers of pools. The pool has a loose membership, in which pool members are not aware of one another, except for the manager. Any Core can be the manager of the pool, but the pool manager cannot be a member of any other pool. You can have up to 32 Cores in one pool, not including the manager.

The pool is dissolved when the manager is no longer available (unless the manager has an HA peer). Management of a pool can be taken over by a failover peer. However, a member failover peer cannot be managed by the member pool manager through the member, even if the failover peer is down.

For details about HA, see High availability in pool management.

From a performance prospective, it does not matter which Core you choose as the manager. The resources required by the pool manager have minor to no differences from regular Core operations.

This section describes how to configure pool management.

These are the high-level steps:

You can configure pool management only through the Management Console.

Before you begin the next procedure, you need the hostnames or the IP addresses of the Cores you want to add as members.

When a member is successfully added to the pool, the pool manager Pool Management page displays statistics about the members, such as health, number of LUNs, model, failover status, and so on.

A pool manager can remove individual pool members or dissolve the whole pool. A pool member can release itself from the pool.

We recommend that you release a member from a pool from the Management Console of the manager. Use the following procedure to release a member from the pool only if the manager is either gone or cannot contact the member.

When you use pool management in conjunction with an HA environment, configure both peers as members of the same pool. If you choose one of the peers to be a pool manager, its failover peer should join the pool as a member. Without pool management, Core cannot manage its failover peer storage configuration unless failover is active (the failover peer is down). With pool management, the manager can manage the failover peer storage configuration even while the failover peer is up. The manager failover peer can manage the manager storage configuration only when the manager is down.

The following scenarios show how you can use HA in pool management:

For more details about HA deployments, see SteelFusion Appliance High-Availability Deployment.

Cloud storage gateway technology enables organizations to store data in the public cloud and access it using standard storage protocols, like iSCSI, via an appliance on the customer premises. In simple terms, a cloud storage gateway device provides on-premises access for local initiators using iSCSI and connects through to storage hosted in the public cloud using a RESTful API via HTTPS. This approach enables companies to adopt a tiered storage methodology for their data by retaining a “working set” within the data center at the same time as moving older data out to cloud hosting providers.

The individual features and specifications of storage gateway products may vary according to the manufacturer. Such details go beyond the scope of this document.

With Core release 4.3 and later, SteelFusion Core has the ability to support cloud storage gateway technology from Amazon and Microsoft. Depending on the cloud gateway product configured with SteelFusion Core, the cloud storage is either Amazon Web Services S3 (Simple Storage Service) or Microsoft Azure Blob Storage. The Amazon storage gateway product is called AWS Cloud gateway and the Microsoft storage gateway is called StorSimple. These cloud gateway products provide an iSCSI target to SteelFusion Core in exactly the same way as regular “on premises” iSCSI storage arrays would. SteelFusion can now extend the benefits of public cloud storage all the way out to the branch office while continuing to provide the benefits of SteelFusion.

The following SteelFusion Core features are supported with a cloud storage gateway deployment:

The following SteelFusion Core features are not currently supported:

Because SteelFusion sees no real difference between on-premises storage arrays and cloud storage gateway, the configuration of SteelFusion Core remains the same with respect to LUN provisioning, access, and use of these LUNs by SteelFusion Edge.