Why You Should Make Adopting Current Long-Life Releases a Habit
Hey everyone — At Pure Storage, we see many customers who still think about storage upgrades like old-school firmware: “set it and forget it” until it’s forced to change. But FlashArray isn’t firmware — it’s modern, continually improved, and designed for an agile, secure, predictable data platform. That means it’s time to make adopting recent Long-Life Releases (LLRs) a regular habit — not just something you reluctantly do, "when you have to". LLRs should be your standard practice: ✅ Fresh Features, Mature Code Each LLR is built on code that’s been running in production for at least 8 months before it branches. That means you get the innovations from recent Feature Releases — tested, stabilized, and production-proven. You avoid missing out on valuable improvements while still benefiting from enterprise-grade predictability. ✅ Consistent Security and Compliance Aging too far behind, even on an LLR, can expose you to security vulnerabilities and unsupported configurations. By habitually adopting recent LLRs, you ensure you’re in the supported window for critical patches and compliance audits — avoiding fire drills later. ✅ Reduce Technical Debt Getting stuck on very old LLRs can build up technical debt. Skipping multiple versions makes your next upgrade harder, riskier, and more time-consuming. Keeping up with recent LLRs means smoother transitions, less operational friction, and easier adoption of the next improvements. ✅ Keep Innovation Flowing The idea that an LLR is “old code” is a myth. Recent LLRs contain carefully chosen, well-hardened feature improvements. If you wait too long, you lock yourself out of meaningful performance, efficiency, and capability gains that your peers are already using. ✅ Break the Firmware Mentality FlashArray is software-driven, and has a rapid but reliable development model. Treating it like outdated firmware, and you miss the true value. The LLR program is designed precisely to let you safely adopt modern features and maintain enterprise-grade stability — and maintain a predictable cadence. Bottom line? Adopting recent Long-Life Releases, habitually, is the best way to get modern features, maintain security, reduce upgrade risk, and keep your environment aligned with Pure’s best practices. You deserve innovation and peace of mind — don’t settle for less by sticking with outdated code. If you want help reviewing which LLR is right for you, or understanding the timelines, just reach out — we’re here to help you stay current, secure, and ahead of the game.191Views5likes2CommentsActiveCluster Asynchronous
Hello Having question about ActiveCluster Asynchronous is it possible to configure between 2 existing clusters Poland to Germany . Idea is to have ability to perform DR tests in Datacenters located in different country The customer is currently running a configuration based on X20R2/R4. They have two systems in the Poland and two in the Germany. Local replication between arrays is configured using ActiveCluster Synchronous. ################## Reviewed documentation is ActiveCluster over Fibre Channel and ActiveDR or Async is supported on the same system starting with Purity 6.1.3+. ActiveDR must be configured with separate volumes (and pods) from ActiveCluster volumes. ActiveCluster asynchronous works in such way that that both arrays Metro Arrays replicate data to 3d array protection group snapshot only Leveraging asynchronous replication is easy to do, it's a simple matter of defining a Target array in a Protection Group after connecting the array. Once defined in a Protection Group, the Protection Group itself can be moved into an ActiveCluster (our synchronous replication, RPO0 replication service) Pod, where the Protection Group is owned by two arrays. The defined Target can replicate regularly scheduled snapshots to a third array. This Active-Active Asynchronous Replication is shared by the ActiveCluster arrays and in the event that either array is offline, the alternate array will assume ownership of continual snapshot replication to the third array. In summary, you can replicate snapshots as desired between any number of arrays to any other number of arrays, requiring a defined array connection and Protection Group Target. These Protection Groups can also be moved into a pod for sharing between ActiveCluster arrays for disaster recovery purposes as well. The sequence of steps for enabling asynchronous replication: Connect arrays so the source and target arrays are aware of each other Create a Protection Group with desired snapshot policies Add any array to replicate snapshots to the Target field If using in an ActiveCluster pair, move the Protection Group into the ActiveCluster podSolved172Views1like3Comments