Pure Storage

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. I will guide you step by step, making complex tasks easier to understand and execute.

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. For example, you can assign a tag to a collection of volumes and then come along later and retrieve a listing of volumes that match a particular key or value. You can use tags to add application context to resources inside FlashArray. Specifically, in the examples in this blog post, I want to tag volumes with the names SQL Server Instances.

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. And Plan C. Maybe you’ll run out of letters because you’re so paranoid.