System administrator at a library with 11-50 employees
Real User
2022-01-12T15:33:00Z
Jan 12, 2022
It's very well done for what it's supposed to do, and I don't have anything to add, but I would like them to keep it available to the public. SwiftStack is going out of the market. NVIDIA purchased SwiftStack a couple of years ago, and they won't be making it available to the public anymore. Our license is up to March 31st.
The file access needs improvement. The NFS was rolled out as a single service. It needs to be fully integrated into the proxy in a highly available fashion, like the regular proxy access is. I know it's on the roadmap. With some of the hierarchy, old management storage policies, I would like to be able to move data between different types of storage policies. One of the things that has come up before was being able to do distributed erasure coding. Right now, erasure coding is only supported locally redundant. Products, like Scality, support the ability using multiple rings to do erasure coding that's globally redundant.
At the moment we are using Erasure coding in an 8+4 setting. What would be nice is if, for some standard configurations like 15+4 and 8+4, there were more versatility so we could, for example, select 8+6, or the like.
Head of Cloud Operations at a computer software company with 501-1,000 employees
Real User
2019-04-08T05:44:00Z
Apr 8, 2019
I would like to see better client integrations, support for a broader client library. SwiftStack could be a little bit more involved in the client side: Python, Java, C, etc. We don't have a lot of issues, but if we do, we don't really get any support from them at all. It's not really in their business model, but it would be easier to integrate if they supported the clients a little bit better.
Chief Technology Officer at a computer software company with 11-50 employees
Real User
2019-03-31T09:41:00Z
Mar 31, 2019
* The biggest room for improvement is the maturity of the proxyFS solution. That piece of code is relatively new, so most of our issues have been around the proxyFS. * Having the full feature set and the management APIs available, there is a lot of room for improvement there. * The code upgrade process at scale, managing code upgrades at large scale.
Scientific Information Officer at a pharma/biotech company with 10,001+ employees
Real User
2019-02-10T10:06:00Z
Feb 10, 2019
On the controller features, there needs to be a bit more clean up of the user interface. There are a lot of options available on the GUI which might be better organized or compartmentalized. There are times when you are going through the user interface and you have to look around for where the setting may be. A little bit more attention to the organization of the user interface would be helpful. They should provide a more concise hardware calculator when you're putting your capacity together.
Enterprise Architect at a manufacturing company with 501-1,000 employees
Real User
2019-01-02T12:28:00Z
Jan 2, 2019
When I started, SwiftStack was just a deployment model for OpenStack Swift. It did what it needed to do. There may have been some room for refinement procedurally in how to do certain management tasks. Over the years with ProxyFS, I don't know where the improvement would lie - whether it lies with SwiftStack or other vendors - but, in general, we need a model where more third-party companies support REST APIs, open REST APIs into object stores such as OpenStack Swift. I really don't see any great strides being taken to do so. There are a few, but a lot of them do the big players, like Amazon S3, and not the open-source players. The other thing that I've been looking for, for years as an end user and customer, for any object store, including SwiftStack, is some type of automated method for data archiving. Something where you would have a metadata tagging policy engine and a data mover all built into a single system that would automatically be able to take your data off your primary and put it into an object store in a non-proprietary way - which is key. A lot of them say they do it, but they do it with their own proprietary wrappers and then, if you don't have their system sitting in front of it, you can't access your data anymore. I think SwiftStack, with its value-add, that's where they're going. If they do that, they have a storage system that would kill all the others.
SwiftStack focuses on handling large-scale unstructured data, providing software-defined storage, and boosting data scalability and durability.
SwiftStack is known for its proficiency in object storage, seamless workflow integration, and robust support for multi-cloud environments. Its architecture ensures high-performance data access, making it ideal for big data analytics, media asset management, and backup tasks. Users value its flexibility, ease of integration, and strong performance. The...
It's very well done for what it's supposed to do, and I don't have anything to add, but I would like them to keep it available to the public. SwiftStack is going out of the market. NVIDIA purchased SwiftStack a couple of years ago, and they won't be making it available to the public anymore. Our license is up to March 31st.
The file access needs improvement. The NFS was rolled out as a single service. It needs to be fully integrated into the proxy in a highly available fashion, like the regular proxy access is. I know it's on the roadmap. With some of the hierarchy, old management storage policies, I would like to be able to move data between different types of storage policies. One of the things that has come up before was being able to do distributed erasure coding. Right now, erasure coding is only supported locally redundant. Products, like Scality, support the ability using multiple rings to do erasure coding that's globally redundant.
At the moment we are using Erasure coding in an 8+4 setting. What would be nice is if, for some standard configurations like 15+4 and 8+4, there were more versatility so we could, for example, select 8+6, or the like.
I would like to see better client integrations, support for a broader client library. SwiftStack could be a little bit more involved in the client side: Python, Java, C, etc. We don't have a lot of issues, but if we do, we don't really get any support from them at all. It's not really in their business model, but it would be easier to integrate if they supported the clients a little bit better.
* The biggest room for improvement is the maturity of the proxyFS solution. That piece of code is relatively new, so most of our issues have been around the proxyFS. * Having the full feature set and the management APIs available, there is a lot of room for improvement there. * The code upgrade process at scale, managing code upgrades at large scale.
On the controller features, there needs to be a bit more clean up of the user interface. There are a lot of options available on the GUI which might be better organized or compartmentalized. There are times when you are going through the user interface and you have to look around for where the setting may be. A little bit more attention to the organization of the user interface would be helpful. They should provide a more concise hardware calculator when you're putting your capacity together.
When I started, SwiftStack was just a deployment model for OpenStack Swift. It did what it needed to do. There may have been some room for refinement procedurally in how to do certain management tasks. Over the years with ProxyFS, I don't know where the improvement would lie - whether it lies with SwiftStack or other vendors - but, in general, we need a model where more third-party companies support REST APIs, open REST APIs into object stores such as OpenStack Swift. I really don't see any great strides being taken to do so. There are a few, but a lot of them do the big players, like Amazon S3, and not the open-source players. The other thing that I've been looking for, for years as an end user and customer, for any object store, including SwiftStack, is some type of automated method for data archiving. Something where you would have a metadata tagging policy engine and a data mover all built into a single system that would automatically be able to take your data off your primary and put it into an object store in a non-proprietary way - which is key. A lot of them say they do it, but they do it with their own proprietary wrappers and then, if you don't have their system sitting in front of it, you can't access your data anymore. I think SwiftStack, with its value-add, that's where they're going. If they do that, they have a storage system that would kill all the others.