NEDGE is a distributed object storage system designed to provide excellent performance, reliability, and scalability.
A combined NexentaEdge OpenStack Swift API gateway and data node.
The combined data node and OpenStack Swift gateway provide both data storage capacity to the NexentaEdge cluster,
and function as a OpenStack Swift API service.
When used with OpenStack or standalone the Swift gateway provides HTTP/REST based object storage using the OpenStack Swift API specification.
All NexentaEdge nodes need to be connected to a dedicated storage network for cluster communication.
This document is intended for Nexenta Partners and Nexenta customers to aid in the planning and execution of a NexentaEdge proof of concept (POC) evaluation. One deployment option for NexentaEdge leverages Canonical�s Juju management tool. The functionality of the NexentaEdge deployment tool (NEDEPLOY) and administration tool (NEADM) is contained in a collection of Juju charms. Individual charms allow you to deploy a NexentaEdge cluster with a specified number of nodes, add nodes to the cluster, and configure OpenStack Cinder and Swift storage services.
Use this document together with the NexentaEdge product guides and Configuration Guidelines as these documents outline suitable platforms and components for the solution. Additional product information on NexentaEdge can be found at https://nexenta.com/products/nexentaedge.
To aid in the execution of a POC, it is important to know the planned hardware and software configuration as well as the test cases. At a minimum, Nexenta recommends that a list of all components and suggested configuration is created prior to the actual software installation.
Collecting this information and providing it to the resource that performs the installation greatly improves the efficiency of the process and reduces the risk of misconfiguration.
Specific server configurations designed for NexentaEdge can be found in the Configuration Guidelines document, and Nexenta recommends that a minimum of 5 servers are used for POC evaluations that require Block I/O. Functional testing can be done on 3 servers, but it is important to understand that NexentaEdge has been designed to work with larger configurations and production deployments should start at 5 nodes.
When using Block services (iSCSI or NBD) each node needs to have at least one SSD available for Journaling. Additional detail is available in the NexentaEdge Configuration Guidelines.
NexentaEdge make extensive use of modern networking technologies such as IPv6 and Multicasting. As a result, there are requirements on the networking equipment that must be fulfilled for successful deployments. Both Switches and Network Interface Cards must support 10Gigabit Ethernet, IPv6 and Multicasting.
If the switch supports advanced capabilities like Multicast Listener Discovery (MLD) snooping, Data Center Bridging (DCB), Priority Flow Control (PFC) and Enhanced Transmission Selection (ETS), this functionality can be leveraged by NexentaEdge to improve the networking performance and reliability.
A list of tested network switches can be found in the NexentaEdge Configuration Guidelines.
It is not recommended to run NexentaEdge with low-end/low-cost networking equipment as in general, they do not work
well with IPv6, multicasting and do not guarantee non-blocking transfers.
NexentaEdge Juju charms run on supported versions of software. They are:
Each NexentaEdge node must have replicast ethernet adapter connected to a dedicated replicast network. The 'replicast_eth' configuration option of charm must be configured.
Online NexentaEdge�s activation key should be entered into the�activation key� option for nexentaedge-mgmt charm.
By default, NexentaEdge�s charms are deployed without Docker container. To enable this option, set �nodocker� option to �false� in the charm or bundle configuration.
By default, NexentaEdge�s charms are deployed using the �balanced� storage profile. To change storage profile, edit �profile� option on each NexentaEdge charm. Available options are: �capacity�, �balanced� or �performance�.
The nexentaedge-swift-gw charm has mandatory configuration part::
Network interface name of dedicated storage network for cluster communication
Also provides swift gateway options::
Comma-separated list of Swift operator roles; used when integrating with OpenStack Keystone.
Default value is "Member,Admin".
OpenStack region that the NEDGE gateway supports; used when integrating with OpenStack Keystone.
Default value is "RegionOne".
and another configuration options with default values::
Used to specify profile: capacity, balanced or performance. Default value is 'capacity'.
Do not perform docker preparation on node. Default is 'True'
The charm also supports specification of the storage devices to use in the NEdge cluster::
Used to specify comma separated exclude disks list. Exclude
disks list persistently stored and it tells system never use
and always skip it during automated disk layouting. Most common
use case here is to exclude disk(s) used by "other" application.
Note that automated layouting will skip all partitioned and/or
mounted disks by default.
Used to specify comma separated reserved disks list. Reserved
disks list is used to skip disks from automated disk layouting.
Most common use case is to reserve disks for future use.
Boot things up by using::
juju deploy nexentaedge-swift-gw
You can then deploy nedge cluster with swift gateway by simple doing::
juju deploy -n 10 nexentaedge
juju deploy nexentaedge-mgmt
juju deploy nexentaedge-swift-gw
juju add-relation nexentaedge nexentaedge-mgmt
juju add-relation nexentaedge-mgmt nexentaedge-swift-gw
And finally add relation from nedge swift gateway to keystone service::
juju add-relation nexentaedge-swift-gw keystone
Author: Anton Skriptsov firstname.lastname@example.org