Author: Trudie

Puppet Labs recently released Puppet version 4, and has subsequently followed it up with Puppet Enterprise 2015.2. With this release, it’s an opportune time to look at Puppet, what it does, what’s new in this release, and whether it might be useful for your business.

At its core, Puppet is a configuration management system. Systems administrators tell Puppet what the configuration of a host should be; Puppet then enforces that configuration, correcting and logging any configuration drift that might occur. In this way, configuring a large number of system packages identically across systems becomes simple and effective. No longer is it necessary to copy configuration files from one host to another, potentially causing issues if an old version is copied to a new host. Updating the configuration across the enterprise becomes a simple matter of telling Puppet about the change, then letting it enforce it, rather than manually editing every host’s configuration file by hand (a tedious and error prone method at best.)

The benefits of a configuration manager go deeper than the obvious, however. For example, it is easy to configure Puppet to distribute Secure Shell public keys, such that all hosts using SSH have them stored (eliminating a common issue of establishing inter-host trust, and keeping it up to date.)

In the new release, Puppet has cleaned up a number of issues with the Puppet domain-specific language (DSL), removing features that can make it difficult to understand what code is doing, and generally allowing for tidier, more predictable structure in the code. These changes mean that those migrating from Puppet 3.x will need to check their code carefully to make sure it won’t break in the new release; however, they should also make locally written modules easier to maintain in the long run.

Also gone are the Cloud Provisioning tools. These have been replaced with fully supported modules to manage Amazon Web Service instances, and VMware vSphere instances, using the same language used to define other enterprise-wide configuration. Using these tools should make it easy to spin up, and spin down, new fully configured instances in short order, making scale up and development work less painful.

The last new item of note is support for Citrix NetScaler devices, allowing management of NetScaler nodes and pool configuration through Puppet – once again, allowing rapid deployment and scale-up of infrastructure.

So, should your business investigate deploying Puppet? If you aren’t already using configuration management packages (whether Puppet or an alternate solution, such as Chef, Ansible, or Salt), the answer is “almost certainly”: if used judiciously to automate regular business functions, and to aid in streamlining business process bottlenecks within IT, the investment can easily pay off in short order.

All software defined storage (SDS) is definitely not created equal; vendors have released a variety of software to create very different solutions with very different aims. This article will provide a short overview of some popular, established and new software companies.

Nexenta (www.nexenta.com) is at one side of the spectrum with their flagship product NexentaStor, which allows customers to build their own array. NexentaStor will utilise commodity hardware such as 2 servers and disk shelves to provide the storage operating system turning the this underlying commodity hardware into something resembling a typical storage array like a NetApp FAS or an EMC VNX. Nexenta provides reference architectures and does not allow an “anything goes” approach. The main advantage is a generally lower price due to the use of commodity hardware and additional flexibility when it comes to the time of refreshing the hardware – in this scenario it is significantly easier to replace the controllers with the next generation hardware and gain the associated performance benefits for the storage environment. Being software this is not coupled to any specific hardware (within the supported environment). Nexenta is currently working on or has released software for Object Storage, Cloud Connectivity and Orchestration.

PernixData (www.pernixdata.com) is covering a completely different angle of SDS. Their FVP software allows the pooling of server flash (SDS) and RAM to improve the performance of the connected storage for virtualised servers on VMware. Their slogan is to decouple storage performance from capacity. FVP uses a variety of SDSs and/or server RAM on supported platforms (Cisco UCS, Dell PowerEdge, HP DL/BL, IBM x and others) as an additional caching mechanism. A nice feature of FVP is the seamless implementation, i.e. no server or VM reboots are required and no other significant changes in the management of VMs. The implementation can save on capital expenditure for expensive high-performance storage, as with FVP reads and writes are performed locally to fast storage. In addition data protection features are built into FVP to prevent data loss.

A similar approach to PernixData has been taken by Infinio (www.infinio.com), who also aims to improve the performance in VMware virtualised environments. Infinio does not require any additional hardware, but requires the installation of an additional appliance (2 vCPUs, 8GB) on each ESXi server to provide a caching layer to improve storage performance.

More in the expected scope of SDS are the next vendors. AetherStore (https://www.aetherstore.com) was started in 2012 and have just released the first GA version of their software. Pooling all unused capacity on any or all workstations and desktops running the Windows operating system AetherStore creates a secure storage environment at no additional hardware cost – making effective use of unused capacity. Data is distributed multiple times protecting against system failures. AetherStore is targeted at SMB, schools and environments that do not want to invest in separate storage infrastructure.

DateCore (www.datacore.com) call themselves “The Storage Virtualisation Company) and admittedly their SANsymphony-V software has been around for some time. SANsymphony-V virtualises existing storage hardware and can add features like auto-tiering, which in turn can improve performance. Likewise IBM (www.ibm.com) has offered the SAN Volume Controller (SVC) for storage virtualisation since 2003. Both solutions are “in the data path”, i.e. implementation is disruptive as a reboot of servers wanting to use virtualised storage is required.

EMC (www.emc.com) put the emphasis on automation, orchestration and manageability with the ViPR SDS. ViPR lives on the other end of the spectrum to AetherStore (the one with Windows 7 support) and supports EMC arrays as well as a host of 3rd party arrays from Dell, HDS, HP, IBM, NetApp, Oracle and SolidFire (the latter an all-flash array company). ViPRs aim is to reduce the time to provision storage significantly through a self-service portal and automation.

Other companies include Scality (www.scality.com; scalable object store) and StarWind (www.starwindsoftware.com; VirtualSAN for virtualised workloads including Hyper-V). An internet search for “software defined storage” also shows Sanbolic, Maxta, Nutanix, HP, Red Hat, SUSE, Dell, Coraid, Overland Storage, Atlantis USX, StorPool , Compuverde and many more.

Most vendors offer a free trial version. However before trying out any (or all) of these software defined storage solutions, it is important to be clear on

• The goals: What is the SDS supposed to achieve? Cost savings, shorter refresh cycles to make use of the latest technology, longer refresh cycles to enable maximum use of existing hardware, increased flexibility, automation, etc.?
• The implementation requirements: What is necessary to implement the SDS and how disruptive will it be to the existing environment?

One of the recent buzzword is “software defined”. When it comes to storage what does it actually mean? In a similar way, while there is a clear benefit and a clear understanding of server virtualisation, what is actually “storage virtualisation”? To complicate things further, some vendors are now offering storage federation. This article will look beyond the marketing hype and will show some of the available options.

The Storage Networking Industry Association (SNIA) has tried to define the attributes of software defined storage in April 2014 in their paper at the URL below and offers the most comprehensive list of attributes that they consider to be part of software defined storage.

Ultimately software defined means an abstraction level from hardware. In this context software defined is nothing new at all. Once people stopped writing code in assembler, i.e. direct for the hardware, one could say with some justification that this was the beginning of “software defined”.

Most midrange storage arrays have been more or less software defined storage for years. Storage arrays in most cases consist of two powerful servers, which the vendors call “storage controllers” and disk shelves with a variety of SSD, SAS and SATA drives. Emerging vendors use this approach to sell the software component on its own for a “build your own array” approach using standard servers and standard disk hardware. As they are not tied to any legacy requirements yet, they can include data reduction capabilities like compression, thin provisioning and deduplication, built-in cloud connectivity, easy and automated management and additional service level management like auto-tiering. Another use case of specialised software (for software defined storage) is to make use of unused capacity within a server environment, e.g. use unused internal disks to create a secure storage environment by pooling the available disks. Yet another use is to use storage capacity especially around SSDs to reduce overall storage latency by using this capacity as another form of cache.

According to SNIA storage virtualisation is a part of software defined storage. This is also where the boundaries are not clearly defined: both technologies mask the original hardware, but what else is required to turn storage virtualisation into a software defined storage solution?

Storage Gateways are physical or virtual devices that provide connectivity to cloud-based storage. While storage gateways are not essential for connection to the cloud, they can improve performance to cloud storage, increase reliability and resilience, reduce the bandwidth requirement by incorporating data reduction techniques like compression or deduplication and can add additional security features for cloud connectivity.
Physical storage gateways contain internal storage capacity, which acts as another storage tier/cache, i.e. data that is more frequently accessed can be accessed locally on the gateway instead of having to be retrieved from cloud storage. Using a virtual appliance provides the same functionality, but local storage which is allocated to the virtual machine is used instead. Considering that this is not yet a significantly sized market, there is a surprising variety of storage gateway vendors.

Common uses for Storage Gateways are for:
– Access to cloud storage as a lower storage tier
– Backups
– Archive data to the cloud

Some shortcomings for most storage gateways are the points of security and recoverability. All storage gateways offer 256-bit SSL encryption. With entry level devices and especially virtual appliances the encryption key may be vendor-supplied, which may not be secure enough for certain sectors like finance or government. In those areas it would be mandatory to choose a vendor that allows the use of a client-supplied and -owned encryption key. However changing this key will pose new challenges, as in most scenarios the stored data will become unreadable with the old key and would need to be re-read and re-written first. While storing data in the cloud is constantly becoming cheaper, retrieval of data is still comparatively expensive. Before choosing a storage gateway appliance the functionality in the security space should be checked with the vendor to ensure that it fits the requirements.
Recoverability is the second area of concern for storage gateways. If the storage gateway fails, no data will be lost, but data will be more difficult to retrieve and may require increased access to cloud storage. Cloud storage and storage gateways do not satisfy mission-critical requirements, but both are a relatively cheap option to store non-critical data safely.
Keep also in mind that accessing any cloud services will require sufficient bandwidth to the chosen cloud provider.