Demitasse

I mentioned the Cohesity REST API when I looked at the developer portal, now I’d like to show you a little about how to access that API and gather information from your Cohesity clusters. For my example I am going to do some very basic work directly with the API using Python. There are language bindings for Python and PowerShell that make accessing the API simpler, but direct access to the API is also worth illustrating. I chose a couple of basic tasks: reporting on capacity reporting and VMs that are not protected. Below I show how I accessed data via the API, I also posted a video of the same process if you prefer to watch.

Continue reading →

One of the fun elements of being briefed about a product that is not yet released, and probably has not had its form finalized, is that only part of the product is revealed. This week at Pure Accelerate the Pure Cloud Block Store (CBS) was launched in its production form. The CBS is an implementation of the Flash Array that runs on AWS rather than on-premises. In my earlier post about CBS, I talked about the storage architecture, S3 object storage for performance, EC2 Instance Store for a read cache and EBS IO1 for the write buffer. This storage architecture remains in place in the CBS but is not attached to the controller as I thought. The EC2 instances that have the IO1 and Instance Store are called Virtual Disks. The basic CBS has seven of these as a “disk shelf.” The controllers in CBS have boot volumes, all the data and metadata storage are in the Virtual Disks, which is the same architecture as a physical Flash Array. One other element that I did not foresee is a DynamoDB table to store system configuration, rather than having this configuration on the disks.

Continue reading →

Following on from my quick look at using PowerShell with Cohesity, I want to highlight the developer resources page at developer.cohesity.com. The developer portal has a few useful resources for automation around Cohesity, some detailed documentation of the REST API that is the core of all developer access to Cohesity and a repository of sample scripts that you can re-use and re-purpose to your needs. There are samples in Python, PowerShell, and Ansible as well as details of how to build an application to run on a Cohesity cluster.

Continue reading →

Way back in the 1990s I was involved in managing large numbers of Windows file servers, as a central repository of business data. These file servers grew and grew over time, more and more files stored. Many organizations now have years and years of files stored on file servers and high-performance NAS appliances. Over time the knowledge of the value of these files is diluted, but the fear that something important may get lost never fades. IT teams are left as the holders of this business data and must treat every file as if some manager or regulator may demand access at any moment. Back in the ’90s, there was also a dream of Hierarchical Storage Management (HSM) which allowed data to move to lower-cost storage when it was not frequently accessed, freeing space on the expensive and fast storage for more frequently accessed data. At the time, there was no built-in support for data mobility in operating systems, so each HSM product had its own custom file-system driver to redirect access to migrated files.

While I’m teaching the course “Architecting on AWS,” one of the central themes is that the highest value comes from using the specific capabilities of AWS services. Directly uploading your software into EC2 instances is unlikely to give you a great result. Consequently, I am very interested in stories of how on-premises products have been re-platformed to be cloud-native. A little while ago, I had the opportunity to sit down at the Pure Storage office in Mountain View and hear about how their hardware arrays become a cloud platform. We looked at the dual controller Flash Array product in our Build Day Live event with Pure; you can watch those videos here. Soon you will get all of the goodness of the on-premises Flash Array in a cloud-deployed form. I was very impressed that the Pure Storage team chose to use the native features of the AWS platform to deliver the same features as their on-premises hardware.

Continue reading →

In my last blog post, I took a look at using your Cohesity cluster to host file shares, which are called Views in Cohesity. I finished with the point that these file shares might hold valuable data and need to be protected against data loss. Your other data is protected by copying from its location to your Cohesity cluster, but a failure that affects Views on a Cohesity cluster is likely also to affect the data protection copies on that cluster. The good news is that we already know how to protect against a Cohesity cluster failure, and therefore need only apply these same protections to Views. We can archive to the public cloud, replicate to another on-premises Cohesity cluster, and replicate to a Cohesity cluster in the public cloud. The Protection Policy for your View should include archiving or replication to ensure data protection against data loss if your Cohesity Cluster is destroyed. Bear in mind that a Cluster outage is likely to result from a human error or some significant disruption such as a data center flood or fire.

Continue reading →

If you had built a scale-out storage cluster, why would you not make it usable as a filer? One thing that we know for sure is that data storage requirements will keep growing. A scale-out storage platform that allows you to buy capacity progressively as your needs grow might be a great solution. Having integrated data protection will be a great bonus. The Cohesity name for file sharing from their cluster is Views. A View can be an NFS or SMB file share and can be an S3 compatible object-store. The default is for the View to be all three, although in this mode the S3 store is read-only with object ingestion via the file share interfaces. If a View is setup as S3 only, then it is read/write accessible via S3.

Continue reading →

Early in my career, many years ago, I was the sole IT person for a small call center business. As the only IT person, I was also responsible for some of the phone system, and everything else that plugged into the wall (including a mechanical letter folder.) Of all the varied tasks I had to complete, the one I hated was preparing the monthly report on IT and phone performance. I had to assemble lots of statistics from a variety of sources into the standard report form. Like all management reports, only the first paragraph was every read. I would spend a day and a half putting together the report and the graphs with the sure knowledge that my work would have no measurable impact anywhere in the organization. I would have loved a tool that would automate the data compilation process and output the graphs and report document for me. At Tech Field Day 19, I learned that there is a whole category of products dedicated to freeing people like me from the tedium of creating those reports. Tech Field Day disclaimer link. Robotic Process Automation (RPA) is the category of products that automate repetitive manual tasks.

Continue reading →