Fishworks RFE (2)
The Sun 7000 Storages have many old, old, ZFS replication problems…
Some are ZFS old problems, and other old problems from fishworks itself…
– We can not replicate per dataset, just entire projects. The only way to replicate one dataset, is create a project for each dataset… well, why i want to create directories to put just one file inside of each one?
– If we do a manual replication, and that replication runs for 10 days and fail, we do not have the replication as a whole. We loose the snapshot that was created for the replication too.
– If the replication fails, all the datasets fail. If we have a project with 10 datasets, each one 10TB, and the replication fails after a week, we loose everything.
– We cannot see the replicated datasets, just the project. Even with read only access. You need to believe your data is there. You need to clone the project to see it…
– You cannot take a snapshot while the replication is running (what??? This is ZFS B/C), and the replication can run for a lllllonnnngggg time.
– If you remove a replication schedule, you loose all the snapshots related (now you have two problems instead of one), and run because your storage will go down!
– If you have a storage with 5TB of data, and your replication schedule fail, you will not have the storage replicating anymore. The performance is from ZFS B/C too… Actually, the only way to have it working again, is removing the scheduled replication (again: run!), loose all the snapshots, and start a full replication again (a little chance for a “X” TB replication actually work).
– Replication performance is terrible!
Seems to be a really nice product in the performance perspective, but we need to improve the reliability, and the replication needs to come to 2010. I remember that kind of problems using the first version of ZFS on Solaris 10.
We see a great product that we really want to Oracle improve it, because we want to use it for real. But right now our home made ZFS storage is much better in general. I think Oracle/Sun can do a better job than us assembling a storage system, we are not a hardware manufacturer. And i was expecting a fix procedure more clean than reinstall (update firmware) for fix any kind of bug.
peace
Boa tarde! I’m glad to see you’re liking the 7000, at least outside the
replication experience…
You’ll be glad to know that we’ve been focusing on replication flexibility,
reliability, and performance, and while I can’t say anything too specific, I
think you’ll be happy with some of the changes we’re making both in the not-too-distant future as well as long-term. Stay tuned.
That said, I haven’t heard about some of these problems before: neither removing replication actions nor destroying snapshots should ever cause your storage to go down, and there should be no problems at all with creating snapshots while replication is running. I’d get in touch with support so we can get to the bottom of those issues. Keep us posted.
Re: upgrades: this is a pretty complicated problem in general, but the way we solved it was deliberate. I hope to write more about this soon, but to start, consider this: would you rather run a production storage system on a combination of software that’s been fully tested by the vendor, or are you really okay running with a garbage barge of one-off patches and hotfixes, the combination of which has never been run outside your own data center?
We used ZFS for over 3 years facing many problems and spending a lot of time.
Then we went with Netapp and saved time and money..
Hello David, it’s nice to hear something from inside… ;-)
Thanks and i hope we can get this corrections in this storage product as soon as possible, because replication problems is a “no go” for the solution.
Marco, we actually do not have problems with ZFS… we have PB of storage on ZFS and it just works. The problem is some “bad assumptions” IMHO from the fishworks team, and the very old ZFS version i think they are using in the product.
Leal