Welcome to our blog series on using the Pure Storage PowerShell SDK2. In this series, we will provide you with practical insights and examples on how to harness the power of the Pure Storage PowerShell SDK2 to enhance your storage management capabilities.
Throughout this series, we will cover a wide range of topics, including performance data gathering, snapshot management, performance bottleneck identification, and resource management within your FlashArray and Cloud Block Store.
Introduction Purity is the operating environment that runs Pure Storage products like FlashArray and Cloud Block Store. Starting in Purity 6.0, you can assign tags to objects. This post shows you how to perform some basic tagging operations for volumes.
What’s a Tag and Why Do I Care? A tag is a key/value pair that can be attached to an object in FlashArray, like a volume or a snapshot. Using tags enables you to attach additional metadata to objects for classification, sorting, and searching.
This post introduces you to the Pure Storage FlashArray OpenMetrics Exporter. It shows you how to get started quickly using Docker Compose so you can monitor your Pure Storage FlashArray environment.
I implemented this in Docker Compose since that handles all the implementation and configuration steps for you. It specifically configures Prometheus’ data source and a Grafana dashboard for monitoring.
Tip: If you’re building a persistent monitoring solution, I suggest using a dedicated Linux server running Docker Engine (Server) for Linux.
At work, I get to work with some fantastic tech that pushes the boundaries of performance. I needed to do some performance testing from a Windows server into a FlashBlade using s3. I reached out to a colleague of mine, Joshua Robinson, who told me about s5cmd. s5cmd is a very fast, parallel s3 compatible command-line client.
Check out Joshua’s post for some performance numbers. Here’s a direct quote from his post.
By Argenis Fernandez
This post is archived here. Pleae reach out to me, Anthony Nocentino if you have any questions.
I gotta admit, some of you are really hard to convince. I’ve been saying for years that given a large enough database size (or a really small RTO storage based snapshots should be Plan A for recovering the database in the event of a disaster. Yes, you will have a Plan B, likely native backups.
