-
Thanks for the question. First let me say these are three completely different animals. I'll summarize here and make some comments in the main article page:
XIV is a completely new type of system and the philosophy of managing XIV is absolutely the opposite of traditional arrays such as EMC's CLARiiON. XIV relies on virtualization and lower cost SATA disks. Please see the link I placed in the article for a further description - but to summarize. XIV is all about trading off the ability to 'tune' the system and rather allows the user to let the system manage itself. XIV spreads the data throughout the array to improve performance and automatically manages the placement of data. It is designed to be a 'hands off' system. In our view it's designed to be easy to manage, straightforward, 'good enough' storage performance for many applications. There are some situations (e.g. 100% cache read miss with random I/O where XIV will not perform well).
XIV has similarities by the way to systems from Compellent and 3PAR that you may want to consider as well.
CLARiiON is at the other end of the spectrum. It is the world's most tried and true and popular traditional array. Very reliable backed by EMC's great service and field tested, proven. It is like a mid-range modular rock - very solid and well tested. With CLARiiON the storage admin has many more 'knobs to turn' and will do the management and the tuning. Customers that have the skills to do this love CLARiiON. Those that don't may find a system like XIV easier to manage. You should consider CLARiiON in situations where you have the skills to manage disk arrays and don't mind (and actually prefer) the ability to do manual intervention. If you never want to mess around tuning disk arrays this is probably not the array for you. On the other hand if you NEED the ability to manage LUNs CLARiiON is rock solid and EMC and its channel provide tremendous support.
EVA is a product that was an early instantiation of virtualization. It has some of the attributes of XIV and some fo the attributes of CLARiiON. Frankly the best reason to go with EVA would be that you have a strong relationship with HP. Otherwise there are products our there that are considered more advanced, more reliable, easier to manage, etc.
Again. Please see the links in the main article - they may be useful... and please feel free to ask more questions here - we'll ask others to weigh in.
Posted By:David Vellante| Fri Feb 26, 2010 08:14
-
I am a Storage Architect with Compellent so let's get that out of the way.
Now in a previous professional life Ive been in your shoes and the thing you have to realize is that everyone selling you storage is selling to thief strengths and features.
What would be helpful in giving you advice is understanding your requirements and focusing on that versus a comparison of your finalists (which David did a great job on by the way).
So what are you looking for in the solution?
Posted By:John Dias| Fri Feb 26, 2010 08:34
-
David,
I agree 100% with you about XIV, it's not very suitable for 100% random workloads (i.e. databases) for its architecture and latencies of disks/architecture. IBM is still reluctant to publish benchmarks and show performance details!
If the customer wants a next generation storage system he needs to consider Conmpellent, Data Progression (automated tiered storage) may be a good solution in SAP environments (we are experiencing very good results migrating ERPs data from other storages).
About old generation storage HP and EMC I'm very doubtful! Ok EMC and HP are more famous brands but their storage needs a lot of work for tuning, provisioning, management... a lot of their virtualization capabilities are still immature (i.e.: constraints and limitations of Thin provisioning, wide striping, snapshots, and so on).
Enrico
Posted By:Enrico Signoretti| Fri Feb 26, 2010 08:34
-
John's comments about requirements are very important. Kovid - what are your requirements? We know SAP. What kind of shop are you (size, skill sets, existing storage)? And what are your objectives - performance, do you want the ability to 'turn knobs' do you have the expertise to tune storage? Do you want to 'set it and forget it?' How much automation do you desire?
Do you have existing strong relationships with IBM or HP or EMC?
If you can answer some of these questions we can be more useful. -thx
Posted By:David Vellante| Fri Feb 26, 2010 08:38
-
Hey sorry, saw a typo - I meant "everyone is selling to THIER strengths" not "THIEF" hope that didn't tick anyone off.
Posted By:John Dias| Fri Feb 26, 2010 08:41
-
So, instead of going at this by a merely storage view of things, let's see the other side. Some questions that come up when I read your post:
* What "SAP" are you installing?
- Saying that you are installing SAP is like saying you are driving a car. It won't offer any other details. Are you installing a Netweaver 7, CRM 7, ERP, BW or something else, perhaps even a combination? A BW will usually improve from an array that offers performance for small random I/O. A CRM 7 is not that dependent on the array, having application servers with plenty of RAM will have a far greater impact than most arrays would have.
* Are you using the array solely for SAP software?
- My guess would be no? Usually if you have such an array standing around, it won't take long before you start storing other stuff on there. That might also need to be taken into account.
* Do you want to perform exotic stuff?
- Do you want to create clones of running SAP installations and put them in your Dev or QA environment? If so, do you require full clones, or snapshots or something else?
* Are you considering virtualizing your SAP environment or perhaps even your regular environment?
- As David already mentioned, some arrays are better up to par with features that can support you in that area.
Answering your question is quite hard without knowing the parameters you have set up for your planned environment. Depending on what you want to do, it is going to be easier for the people here to give you some advice that might actually help you more than just saying "Compellent/EMC/HP/Whatever works well on SAP". :-)
Cheers,
Bas
P.S. In terms of disclosure, I actually work for SAP.
Posted By:Bas Raayman| Fri Feb 26, 2010 09:08
-
Bas,
Your comment is very complete and clear.
when I spoke about Compellent my point was only on better management and self tuning features... and these are application independent.
Regs,
Enrico
Posted By:Enrico Signoretti| Fri Feb 26, 2010 09:22
-
Fair enough Enrico. :-)
Posted By:Bas Raayman| Fri Feb 26, 2010 09:23
-
Dear David and Bas,
Thanks for the reply,
I am answering all your queries here
1) We are going for Netweaver 7, crm, ERp , BW, ECC and also IS auto,
2) This is for oracle, sap, for application, for SAN boot etc.
3) we would be requiring clones, dev, QA stuff,
4) we would like to vitualise our full ennvironment
5) We would also like to migrate from EVA 5000 to the new box for our legacy software
5) We shall be targetting aroun 3000 users with ESS and EP+BW
6) we have a strong relationship with HP who is our Fms partner + relationships with IBM and EMC
7) We shall be going in for customisation to the tune of 20-25%
Posted By:kovid ranjan| Fri Feb 26, 2010 11:23
-
Hi Kovid and everyone,
Thanks for posting the specifics, now your requirements are more clear (I hesitated to post before and did not want to make it sound like an ad).
As Bas said some arrays are better suited to some tasks than others.
It's also worth noting what kinds of systems SAP and Oracle themselves are using heavily. I don't think XIV and EVA are in the mix that much - no disrespect to IBM or HP. You have one vendor they're using as a finalist, but completely omitted in your list the one they use really heavily (as in many many PB).
In purely random workloads that won't fit in the XIV cache, expect rather mediocre performance (there, I've said it). However - if your apps DO fit in the XIV cache, expect stellar performance. Otherwise, the back-end SATA drives become a bottleneck, plus there can only be 180 of them (at 40 IOPS per SATA drive if you expect under 20ms response for OLTP, do the math).
You COULD install SAP and Oracle on almost anything of course, I've seen customers also use Equallogic, LeftHand, pretty much anything you can imagine. The apps worked but some key functionality was always missing (i.e. a customer had to shut down all apps in order to take a snapshot! Not ideal).
Ultimately it's not so much about the hardware but about the supporting software.
Application awareness is important - for instance, it's much easier for the array to take proper snapshots and clones plus replicate if it actually knows how to interface with the application so that the resulting snaps, clones and remote replicas are usable and consistent.
It's also useful to be able to interface with Oracle and be able to do granular operations such as selectively restore parts of the DB without needing a separate backup tool.
Many arrays have limitations regarding snaps and clones. Very, very few don't.
* CX can only take 8 per LUN (and if they are snapshots they can slow the array down), can be app-aware with Replication Manager
* EVA I believe can take more but they also slow the array down, not sure if they are app-aware
* XIV I believe doesn't suffer from the slowdown taking snaps but I don't believe it is app-aware.
Regarding virtualization, would you like to save a ton of space by deduplicating your VMs regardless of what protocol you use for VMware?
Would you like to be able to provision even thousands of VMs without space impact? (and actually INCREASE performance)?
Maybe start here: http://www.youtube.com/watch?v=zAHGceV1JHY
Then http://www.youtube.com/watch?v=ixKHEsXJzIw
Then http://www.youtube.com/watch?v=7FJMNG5VdI8
And http://www.youtube.com/watch?v=ekoiJX8ye38
Finally:
http://bit.ly/aUZRUO
http://bit.ly/dsj1sS
http://bit.ly/bfquqm
You can look at my profile to see the same info but I'm a proud and happy NetApp employee!
Thx
D
Posted By:Dimitris Krekoukias| Sat Feb 27, 2010 11:44
-
Okay, I'm going to address some of your requirements with some comments.
Firstly, you talk about doing dev/qa; I am a great believer that this should be done on a different array to that you are running production on. Lots of reasons, from potential performance impact of running performance testing on the box you are running production on to data security issues.
And depending where you are and you talk about CRM for example, you may find that you've got to do alot of data sanatisation work to prevent you testing on live customer details.
I also note, no mention of Disaster Recovery or Business continuity concerns? No mention of Recovery Point or Recovery time objectives; all of these have potential impact on the array that you buy.
Dimitris talks about NetApp arrays; you can buy these from one of your existing partners in the form of nSeries from IBM if you so wish. Do not let IBM push you down the XIV route if you do not feel comfortable with this. You could also take SVC and whatever other cheap disk IBM want to sell you.
Clariion is a fine and easy to manage array, as are the others you talk about; actually, if anything CX is at times under-pushed by EMC who have a habit of trying to push Symm over everything else. Dimitris also talks about Replication Manager; yet another EMC product which EMC forget about despite it being a very competent and easy to use product now.
I'd be uncomfortable with HP storage at present, simply because the HP roadmap is not clear. But as per usual, you need to factor in the cost of change, you have HP storage now and you are comfortable with it; if you put another vendor's storage in, there will be migration and the inevitable re-training costs.
Just some thoughts anyway...I have nothing to sell you!
Posted By:Martin Glassborow| Sat Feb 27, 2010 12:44
-
Thanks guys for weighing in. Through backchannels I've asked the three vendors - IBM, HP and EMC to provide any reference architectures they have around these specific arrays in SAP use cases. I'll also ask for anything around RPO / RTO per Martin's suggestion.
I know IBM has Redbooks, EMC has Proven Solutions and I think HP also does some ref. architectures out of colorado springs. These can sometimes be good freebies and increase confidence in the specific application environment.
I'll post what they send along.
Posted By:David Vellante| Sat Feb 27, 2010 02:26
-
Martin is right, if it's easier to buy from IBM you could buy NetApp through them as the N-Series. Or, you can start a relationship with NetApp, but I know how vendor approvals work sometimes.
Just make sure you're not painting yourself into a corner by limiting your choices.
Here are some NetApp whitepapers and technical reports that may be of interest... if you want to see more, just to go netapp.com, look at the library link at the top and try whitepapers and technical reports, then search for the keywords you're interested in. All content is freely available.
http://media.netapp.com/documents/tr-3631.pdf
http://media.netapp.com/documents/tr-3645.pdf
http://media.netapp.com/documents/dr-validation-for-sap-solutions.pdf
http://media.netapp.com/documents/tr-3689.pdf
http://media.netapp.com/documents/wp-7087-1009.pdf
http://media.netapp.com/documents/wp-7054.pdf
http://media.netapp.com/documents/wp_3540.pdf
http://media.netapp.com/documents/sap-coil.pdf
http://media.netapp.com/documents/istreet.pdf
http://media.netapp.com/documents/tr-3797.pdf
http://media.netapp.com/documents/tr-3734.pdf
http://media.netapp.com/documents/tr-3485.pdf
Posted By:Dimitris Krekoukias| Sat Feb 27, 2010 10:55
-
Kovid,
So what I've read is that you have quite the mixed environment here. As Martin already said, I would also recommend splitting up your DEV/QA and productive environment.
Since you are virtualizing your entire environment I this places some different requirements on your environment. Take into account that creating clones will also require you to have an according network setup. You will either need to perform some after cloning steps (change SIDs, remove batch jobs, remove application server, replace licenses, install users, etc) or if you don't want to do that, you need to set up some network fencing and clone your entire landscape since your cloned systems will automatically try to log on to their application server, perform batch jobs and such. If you want to use snaps to create clones, keep in mind that starting clones will affect performance on your clone source.
You wrote that you are targeting 3000 users, but I'm assuming these are named users? If so, you will have somewhere around 30 to 50 concurrent users, which would mean that array performance is only a minor impact to your user experience. If you are talking about 3000 concurrent users, I would seriously consider an active/active array.
Another thing to remember is that if you are fully virtualizing, you can use virtualization features like DRS or live migration, but a single array will still be a single point of failure. Depending on your budget, you might want to consider keeping your current array, purchasing another "low price" array and introduce a storage virtualization controller like SVC, Invista, V-series or USP. This will introduce some useful features and offer some additional features that your array natively might not have.
All in all, I would say the the two major players here are your BW, and your cloning requirement. For the BW systems the arrays mentioned here are all ok since they offer good performance for a low number of I/O streams that are quite random in their behavior (BW batches fit that profile). For cloning you need to consider what type of cloning you want to perform, perhaps you could provide some more specifics here?
Boot from SAN is not really that much of an issue since you will only have your virtualization hosts booting a small virtualization system from the SAN, and all of your VM's data files will reside in the SAN (at least, that would make sense to me) and you won't be booting all of the VM's at once.
All in all, I would say that most arrays mentioned will perform their job just fine, but as stated introducing a storage virtualization controller might be an option?
Would like to know what you think about the options suggested. :-)
Cheers,
Bas
Posted By:Bas Raayman| Sun Feb 28, 2010 05:44
-
Disclosure: I am an EMC Employee.
I'm not going to carpet bomb the place with whitepapers as I'd be here all day but I'd have a look at the following around SAP and the CX4.
Leveraging EMC CLARiiON CX4 with Enterprise Flash Drives for SAP Deployments.
http://www.emc.com/collateral/hardware/white-papers/h6903-leveraging-clariion-cx4-enterprise-flash-sap-wp.pdf
Page 7 onwards has some interesting details and I'd follow up on the docs listed in the reference section.
Leveraging EMC CLARiiON CX4 Fully Automated Storage Tiering (FAST) for Enterprise Application Deployments.
http://www.emc.com/collateral/software/white-papers/h6951-leveraging-cx4-fast-wp.pdf
Page 10 onwards has a SAP specific usecase when using Fully Automated Storage Tiering.
The customer involved (and Wikibon) should contact their local EMC team to discuss the minutia of a SAP deployment with the EMC-SAP Alliance team.
Posted By:Mark Twomey| Sun Feb 28, 2010 10:24
-
Having just read Kovid's additional comments here's a Celerra Unified Storage Blueprint EMC designed for SAP.
http://www.emc.com/collateral/software/technical-documentation/h6418-unified-storage-sap-design-validation-celerra-oracle-blueprint.pdf
I include this as it's designed around 1000 users and should scale upwards in a building block fashion.
Posted By:Mark Twomey| Sun Feb 28, 2010 10:54
-
Per Bas Raayman's comments about storage virtualization and single points of failure; you may want to inquire about HP's SVSP - it's a private label version of LSI's SVM and given your relationship with HP might fit as a means of simplifying migration and squeezing more out of installed assets.
Posted By:David Vellante| Sun Feb 28, 2010 07:30
-
Dear David and Bas and others who have helped me ,
To add to information we have a DR side with and RTO of 2 hours and RPO 0,
Also the no of users are 3000 named users , concurrency may be depending on the usage as we are implementing SAP for the first time.
Also since we are toying the option of HP and IBM for the entire hardware deployment, does it mean that we should go for EVA if HP is selected and XIV if IBM is selected , both are strong contenders for the supply of hardware.
Regarding the SVSP, we did study the option , but have kept it in the next phase if we go for HP as the cost vs output are not matching
Kovid
Posted By:kovid ranjan| Sun Feb 28, 2010 10:48
-
Those are pretty solid numbers. Since you are talking about RTO of 2 and an RPO of 0, make sure that whatever option you choose supports a synchronous mirroring option (I don't know the distance, but since you talk about 0 RTO I assume it's not so far apart that you can't use synchronous, or have a bunker site in between).
In regards to the concurrent users, it is dependant on the environment, but I would say that 30 to 50 concurrent queries would be a good start.
I don't know if you require the option of cloning to your DR site and creating clones from clones and the ability to clone to any site you please. If so, you will probably see great value in a storage virtualization controller.
XIV is an option, but my personal opinion is that just an XIV does not really make sense in your setup. You will most likely quickly run in to the capacity limits of the XIV. A solution would be to use an SVC, you can create a cluster of those and achieve a HA/DR solution and increase the utilization of your storage array(s).
Posted By:Bas Raayman| Mon Mar 01, 2010 02:37
-
How far is the DR site?
Total amount of data?
Latency?
Bandwidth?
Packet loss?
Are you going to use Oracle RAC or standard?
How many clones?
And why is IBM pitching you the XIV so hard when they have potentially more appropriate SAP and VMware platforms?
Finally, I understand partnerships, but sometimes the partner just doesn't have a best-of-breed product.
If it becomes a poliical game, technology goes out the window. I've seen it happen too many times for comfort.
D
Posted By:Dimitris Krekoukias| Mon Mar 01, 2010 03:26
-
IBM will push XIV above anything else unless you are very firm with them; they are absolutely desperate for footprint. This is not to say thatXIV is wrong in your situation but it would need testing and that includes proper volumetrics. I would be looking for IBM to underwrite the solution and set acceptable performance targets; they then fix at their own cost. If they won't do this, then perhaps that shows that they have some limited confidence in the solution they are proposing.
Please also note, that the XIV guys appear to work independantly a lot of the time; if you have an IBM account manager, you should ask to see a non-XIV sales guy as well. IBM have a huge portfolio of storage products, make sure they sell you the right one for you, not the right one for the account manager's targets.
Bas makes great points about the RPO/RTO; you need to be within synchronous distance or a bunker site or something like Axxana to give you the synchronous performance you want to achieve. Also don't forget that disk-based replication is not your only option.
And Dimitris is right, sometimes the partner does not have the best of breed product...but that might not be a problem, second best might be good enough.
What do you want to achieve? Evaluate on those criteria, it doesn't necessarily have to be the best product; it just has to do what you want.
Posted By:Martin Glassborow| Mon Mar 01, 2010 04:14
-
Dear Bas, Martin and Dimitris,
I am answering your questions
How far is the DR site?
around 250 KM s
Total amount of data?
at startup it is around 8tb expected
Latency?
less than 10ms
Bandwidth?
34mb
Packet loss? as we use wan scaler for the line, not much
Are you going to use Oracle RAC or standard?
SAP has suggested not to go for RAC hence normal with oracle dataguard
How many clones?
expected one for Test, other for dev
And why is IBM pitching you the XIV so hard when they have potentially more appropriate SAP and VMware platforms?
They are telling that the latest technology and storage replication this is the best mix
Finally, I understand partnerships, but sometimes the partner just doesn't have a best-of-breed product.
with IBM we shall be going in for a new partnership, with HP we have a strong relationship
Posted By:kovid ranjan| Mon Mar 01, 2010 10:30
-
At 250KM and 10ms latency it will be difficult to get 0 RPO replication. Performance will suffer in order to provide 0 RPO (indeed most vendors won't even support synchronous replication over that distance.
As others said, don't feel compelled to have IBM push XIV. Other platforms have been running SAP in large shops for years now, with tons of references.
HP also offers the XP line, that's actually rebranded HDS and very decent gear. EVA replication not the strongest.
Check some of the links I sent. It goes beyond the hardware and ultimately it's about your applications and how the array interfaces with them, not about the array tech itself.
I recommend you have NetApp and EMC both talk to you about SAP since both companies have strong solutions that are proven, and tons of references.
IBM has a problem with controlling the XIV reps since they are not yet integrated with the rest.
Ask IBM why are they not pushing N-Series or SVC in front of something else. And what specifically does the XIV do for SAP - as in, what software does it have that directly interfaces with SAP, Oracle and also VMware.
ultimately - expand your horizons by a little bit. I may be biased but you're completely overlooking a company that has really tight integration with VMware, Oracle and SAP.
Be careful so you don't end up with fifth or sixth best, not even second best.
D
Posted By:Dimitris Krekoukias| Tue Mar 02, 2010 12:27
-
Okay, with the distances you are talking about and the latency you are talking about; an RPO of '0' with traditional technologies is pretty much unachievable without incurring a massive impact on your performance.
You need to consider either going down to an asynchronous replication or a multi-hop type implementation.
XIV's asynchronous replication is a relatively new addition to it's feature set; I would ask for references running XIV, SAP and async replication.
And then talk to the rest of IBM's storage business, NetApp, EMC and HP.
Posted By:Martin Glassborow| Tue Mar 02, 2010 03:48
-
If you're looking at HP EVA you should be asking HP about the following technologies.
CA-EVA for seamless data migration from your EVA5000 and on going DR replication, sync or async @ the array
http://bit.ly/9hV7GL
The above can also be combined with CLX-EVA to provide stretch clustering between DR sites over distance, providing automated failover between sites.
http://bit.ly/a2NzWT
If you need to take online copies, whether snaps, snapclones, mirrors or combinations of these look at BC-EVA. Note unlimited clones or mirrors or up to 64 snaps per LUN.
http://bit.ly/akX9MR
If you need full SAP integration then check out SSC-EVA combined with the above.
http://bit.ly/b3Q9Re
Lastly if you really feel the need to virtualize the EVA further then check out SVSP.
http://bit.ly/197aND
Posted By:cleanur| Tue Mar 02, 2010 10:26
-
yes Dimitris , Martin , Cleanur and other friends, I think i misunderstood the RPO, it is 2 hours and rto of 30 minutes and we have to go for Async mode only, IBM is proposing Async storage replication witth XIV and HP with a data guard on EVA 8400.
Posted By:kovid ranjan| Tue Mar 02, 2010 11:33
-
Why not Dataguard for IBM as well? Make your solution completely storage agnostic? Just a thought. Always consider other options as well as doing replication in the array.
This may be heresy for the storage vendors but it is an option that should always be considered. And just make sure that any DR solution proposed is easily testable and testable with no disruption to the business, otherwise you'll never be allowed to test.
Posted By:Martin Glassborow| Wed Mar 03, 2010 03:36
-
Not heresy Martin, you speak the truth: If you can afford Dataguard, it's a great technology. Since it can do other stuff like migrate between architectures and even replicate from FC to NFS, it doesn't care...
Posted By:Dimitris Krekoukias| Wed Mar 03, 2010 04:34
-
Glad we have agreement on zero data loss at asynch distances. I know Axxana has announced such a capability with EMC Recoverpoint but otherwise Martin is right - pretty much unachievable.
Martin's point about 'testable' is critical. I know many clients that can't/won't/don't test failover/failback because it's too disruptive to the business and too 'risky.' There's irony for you...too risky to test!
Posted By:David Vellante| Wed Mar 03, 2010 10:45
-
I can only agree with David and Martin. You _need_ a failover/failback test window or option. It's like saying, "I trust on my backup". Having a backup will get you nowhere without having tested the restore.
Depending on what standards you use, my opinion is that something like a failover/failback test should always be a mandatory part of the service delivery. You won't be able to guarantee your RPO/RTO objectives if you don't test and validate them, simple as that.
Posted By:Bas Raayman| Wed Mar 03, 2010 11:22
-
I'm going to weigh in a bit on the RPO=0 requirement. In the interest of disclosure, I am an external advisor to Axxana, whom Dave Vellante mentioned. There's another guy who could weigh in as well, who is Alex Winokur, the CTO of Axxana, and the former CTO for XIV. He knows more than a little about replication. As Dave said, Axxana is the only commercially available solution today that can offer an RPO=0 capability over any distance. Their product, the Phoenix System RP, has completed comprehensive EMC eLAB certification and is available through EMC Select, so is fully supported by EMC. It leverages the asynchronous replication available from EMC RecoverPoint, supports the CLARiiON storage platform and stores the deltas between a synchronous and an asychronous replica in a disaster-proof, solid state storage system. The deltas are then resynched in the event of a disaster. I'll post a separate article on how that works, but in the meantime, I would recommend a phone call to Allan Scott, the GM for North America. He can be reached at 1-781-304-4890 or by email at allan.scott@axxana.com.
Posted By:John T. McArthur| Wed Mar 03, 2010 12:52
-
Decent perspective from @dfloyer on the risks of testing DR:
http://wikibon.org/wiki/v/Disaster_recovery_plan_too_risky_to_test
Posted By:David Vellante| Thu Mar 04, 2010 09:10
-
Disclosure: I am an HP employee working as a solutions architect in the HP StorageWorks division with specific interest in SAP.
When it comes to relationship with SAP, HP is probably one of the best partners with SAP, not only is more than 50% of SAP installations worldwide running on HP servers, but HP is also one of the largest SAP customers. And like all the other guys will tell you we have also very strong ties into the development and testing of SAP platforms with SAP. So when it comes to having expertise on SAP HP has the resources and people to help with server storage and application questions. For a short overview, just go check out www.hp.com/go/SAP
Now as far as the EVA is concerned, it is and continues to be an important part of the overall HP StorageWorks family. With EVA, HP has offered storage virtualization (and all the benefits that come with it) for many years. EVA customers continue to tell us how easy it is to provision their storage and manage their array. EVA’s virtualized architecture better optimizes available capacity as compared to traditional arrays because EVA automatically spreads data across all the spindles. EVA offers full DR capabilities and, with integration of HP StorageWorks Cluster Extension EVA software, it provides full cluster support failover and failback, as well as integration to SRM for your virtualization environment.
As far as being application aware, checkout HP System Copy for SAP, an application specifically designed to automate the processes of creating online copies of an SAP system, using either snapshots or clones, and includes the renaming of the database and instance. This application, which was developed in close co-operation with SAP, integrates with the SAP TDMS tools to help reduce the size of Dev and QA, providing that data scrambling you need to protect your data. HP System Copy for SAP also integrates with UC4 to help you to automate and improve the refresh operations on systems. Note this is not just a backup or replication management tool with some scripts, it is an application specifically designed for SAP system copy operations. www.hp.com/go/systemcopy
And yes keep in mind HP has a large selection of Storage Solutions, with easy migration paths between arrays, and array families. Almost too many to mention, and having only one vendor to sort out any problems is a great benefit too, much less finger pointing if you ask me.
Posted By:Marcel Duvekot| Thu Mar 04, 2010 02:58
-
Thanks Marcel. I know HP sometimes does best practice reference architectures (e.g. Best Practice in Oracle 11g Backup). Do you have anything like that for EVA in SAP we could review?
Posted By:David Vellante| Thu Mar 04, 2010 03:07
-
Hey Dave -
(Disclosure - I'm an HP empolyee, working as the StorageWorks Category Manager).
Marcel may have insight into more but the team your familiar with at HP (used to be called CFT) has several resources for SAP and StorageWorks. You can find them here: http://h71028.www7.hp.com/enterprise/us/en/solutions/storage-customer-focused-testing-sap.html
Posted By:Calvin Zito| Fri Mar 05, 2010 01:00
-
Guys, I'd like to make one thing clear.
(I am working for IBM as XIV sales, so one could surely say I am biased, but it also means that I know the System I am talking about - and some others obviously do not, and still keep speaking about it - this was aimed at Enrico...)
If IBM pushes for XIV as a solution, it is done in the full light ob a very wide IBM Portfolio. Alternatives could be based on SVC plus low-cost Disk (even DS3000).
So ask yourself the question why IBM has chosen to offer XIV instead of something else. Because they think it is the best solution they can offer - obviously.
Dimitris and Enrico are both making points which are downright false - it does not seem strange to me that Dimitris is telling you to ask for NetApp as he is employed there- but he is telling you to:
"IBM has a problem with controlling the XIV reps since they are not yet integrated with the rest.
Ask IBM why are they not pushing N-Series or SVC in front of something else. And what specifically does the XIV do for SAP - as in, what software does it have that directly interfaces with SAP, Oracle and also VMware."
First: NSeries in Front of someting else...
Because NetApp will not support NAS GW in front of XIV (although it works nicely..)
Second: the whole statment is pure NetApp Propaganda - where you need the (not inexpensive) Software functions you might be right with a NetApp. But putting WAFL in means 40% more Disk space without any benefit, and less performance than in a block-based environment. Most of the ~1750 XIV Systems installed today do run a large percentage of Database Workload, especially SAP, Oracle, SQL and Exchange being the most frequent applications on XIV.
To Enrico: If you really propose Compellent, do show some large References to prove they will still be around when the boxes are becoming old.
Do ask the NetApp Guys how easily you could migrate away from their Box, should, for instance, performance become a problem. They'll tell you 'no problem, just buy the next bigger NAS Controller. Which does NOT speed up the disk access - you'll have to buy spindles or resort to EMC's way of doing things: Buy expensive and failure-prone but very fast Solid State Technology.
But I grant you XIV will be the most cost effective and easy-to-run, albeit not the most flashy solution.
Posted By:Yves Pelster| Fri Mar 05, 2010 09:03
-
@Yves
It behooves every sales person to know their product line, and I would suggest that you may want to get a little more familiar with yours.
1. Both IBM and NetApp fully support the V Series and N Series Gateway respectively, in front of the XIV. It is available by IBM RPQ (Request for Price Quotation).
2. That's the first time I've heard the claim of 1750 XIV installs. It was 1000 in November 2009.
3. NetApp "propaganda" extends to the values IBM espouse for the IBM N series. Where customers require functions to improve the TCO of an XIV acquisition that the XIV doesn't provide, such as NAS capability, it makes sense to do so. The unfortunate starting point of 50%+ capacity overheads of the XIV can't be blamed on NetApp.
4. Your understanding of getting performance from a NetApp system (or the equivalent IBM N Series) is as flawed as the rest of your arguments.
Lastly, you're not doing the XIV or IBM any favours with this. I'd say Dimitirs was on the mark with his comment that IBM has a problem with controlling XIV reps given this set of pretty baseless observations.
Posted By:Alex| Fri Mar 05, 2010 11:56
-
@ Alex....
Ad 1:)
Can I take this as a statement that you declare MetroMirror functionality will be supported in a German Customer set with NSeries Gateway and XIV underneath ? If so, that's news. Hell, you can't commit that although it works. Why ?
Ad 2:
Yeah, we are growing very fast. Which is why especially EMC is trying to keep us out no matter what. There is not a single customer who has yet gone back to traditional Storage after having bought XIV. So get your numbers right, this is official stuff.
Ad 3:
I am a fan of NetApp technology in the midrange NAS Space, and wherever the excellent software stack is really in need. Problem (and it is a local problem in Germany as I understand) is that the NetApp sales force does not see IBM generated revenue in their quota fulfillment, and thus often (not always) refuse to work with us. Apart from that, there are mere market-control RPQs under way (e.g. MetroMirror with XIV) which do not have a technical but rather a marketing background.
Ad 4)
I've sold a lot of NetApp Systems, and my understanding has been totally sufficient to do that, keeping customers happy.
By the way, I am not ONLY an XIV Rep, but can sell anything that's in IBMs rather wide (how about you - hammer and nail topics... ?) storage portfolio.
Thanks for your concern about IBM being harmed by my postings - they are my very own observations and do not necessarily have to do with my employer's view of things.
But I at least (how 'bout you ?) declare who I am in my postings. Without having checked, I think I my assume you're from NetApp ?
Posted By:Yves Pelster| Fri Mar 05, 2010 12:22
-
As much as I enjoy watching a good Vendor cockfight, I suggest we get back to helping Kovid in solving a problem.
Get off your FUD horses (all of you!) and try to suggest a solution that helps the customer. I am more then convinced that putting the other solution/vendor down won't make Kovid buy your product any sooner. Fight with arguments on the value that your product offers, not the value that another solution won't offer. It's not charming and just not appropriate in the question posted here.
Thanks guys (and gals).
Bas
Posted By:Bas Raayman| Fri Mar 05, 2010 12:30
-
@Yves
We're off topic here.
For IBM N Series Gateway support, you will have to talk to IBM. NetApp aren't responsible for what is and isn't certified.
It seems inadvisable to discuss your relationship with NetApp and your internal RPQ process here. One, it's a public forum, and two, it's not addressing the question.
But the 1750 XIV sales; well done. I wouldn't have thought that kind of 1 quarter acceleration was possible, but it appears I'm wrong.
Yes, I work for NetApp. You would have seen that if you had clicked on the Posted By: Alex link.
Posted By:Alex| Fri Mar 05, 2010 12:32
-
@ all: Bas sure has a point.
Agreed, we are not helping anyone here.
There is a lot of FUD against XIV in the market though, and it quite galls anyone whether seller or not, who's understood XIVs concept, to see what's written sometimes.
As an end point to this quarrel: you're wrong. The Metro Mirror functionality needs an approval from Netapp which is generally not granted.
Posted By:Yves Pelster| Fri Mar 05, 2010 12:57
-
Hi boss,
My problem is getting complicated by this type of solutions, I want a justifiable statement which can be put forth to the management
Posted By:kovid ranjan| Mon Mar 08, 2010 01:44
-
Disclosure: I was the CTO of XIV and am now the CTO of Axxana as John has mentioned.
As such I am in a very awkward position to write here. I would have probably kept silent if my name was not mentioned in this thread. I am not an expert on EVA but Clariion and XIV I know pretty well.
1. Performance: XIV performance is quite good in random access environment too and here is why. SATA drive average access time is around 10ms (not 20ms) while SCSI/FC drive access time is 4ms. This is a ratio of 2.5 to 1. Therefore while latency of XIV on single drive is indeed higher than that of Clariion (provided FC drives are installed) however surprisingly the throughput of XIV would be typically higher since it is architected to evenly utilize all drives in the system (even the spare drives) which is rarely the case with other systems. In other system only relatively few drives are really loaded. The typical utilization ratio here is 3 to 1 in favor of XIV hence the improved throughput. As a side comment, it is an important planning question whether you want to use Clariion with FC drives in the first place or go with SATA drives, there is a significant cost difference there and if you go for SATA than XIV advantage becomes even greater.
2. Management and scalability. In that respect XIV is truly the next generation storage; its management is by order of magnitude simpler than any traditional storage that I know. For example since all drives are evenly utilized there are no hot spots and no need for tuning. To really appreciate XIV’s management capabilities you need to talk to those that use it, not those that talk about it.
3. Snapshots. As many as your space will permit, practically without performance degradation. And with the snapshot architecture thin provisioning comes for free very naturally integrated into the overall system
On the other hand there are drawbacks too. If you need less than 40TB of net storage XIV is probably not the system for you and you are probably better off with Clarrion. With XIV even when you need only 5TB of storage say, you will be paying for electricity to rotate at least 72 drives. You will also need a complete rack for this while some Clariion models require less space if you need less storage.
With regards to DR I suspect that at this point of time Clariion with RecoverPoint provide a better solution than XIV async replication. As somebody wrote here, XIV async is a fairly new product which will need time to mature and it does not include the excellent bandwidth utilization the RecoverPoint provides with its WAN optimization capabilities.
As John wrote, with Clariion RecoverPoint and Axxana you can achieve RPO=0 for replication to any distance. As far as I know this is a Clariion’s only unique capability. In addition to that it provides significant saving on communication lines bandwidth and other side benefits like a very elegant handling of link failure that make DR much more efficient. So if DR capabilities are important than Clariion + RecoverPoint+Axxana’s Phoenix RP does provide significant advantage.
And last comment, to really understand the XIV advantages you absolutely need to talk to XIV users, they will provide you with the most authentic information. In fact I am quite disappointed by the fact that none of them wrote here. I guess that 1000 to 1750 customers large enough community yet. I strongly urge them to share their experience. On second thought this comment is true for the other storage vendor users too.
Alex
Posted By:Alex Winokur| Mon Mar 08, 2010 02:13
-
Hi Kovid. We're speaking to an IBM XIV customer running SAP (virtualized) today. About the same size as you in terms of # of users. Will focus on key metrics, performance, DR, clones, migration, etc and report back to you asap.
Posted By:David Vellante| Thu Mar 11, 2010 03:32
-
Ok Kovid...I just got off the phone with an XIV customer running SAP. I told him about you and asked if he would speak with you and he said he would. If you want his contact info - reach me at david DOT vellante AT wikibon DOT org.
Here's what we learned:
*Been running SAP / Oracle for 1 yr on XIV
*About 2,000 users
*Started out at 4 TBs and grown to over 50TB today
*CRM, BI, Portal
*Migrated from an older Symm and a CX3-80
*Virtualized test & dev; not production
*Running SAP clones for test and dev on the XIV which is supporting production
*DR is done through Sunguard - RPO is 2 hours; RTO is 20 hrs
*Performance has been great. Previous arrays had backend spindle constraints. XIV in the POC was doing 80,000 iops. App peak today is 15,000. They don't measure response time diligently so I can't comment there other than to say the customer is very happy w/performance.
I asked if they were worried about doing test & dev clones on the same array as production and he said he was but they've never had a performance issue.
Reasons for going with XIV:
*Cost
*Manageability
*Consolidation of DMX, CX and Dell server DAS
*Ability to support business change (flexibility)
He stressed that he is a small shop and he didn't want to have to keep going back to management to ask for more money. He also stressed that he doesn't have a full time dba and unix admin and storage admin, etc...all his people are cross trained and can manage the XIV and any changes, allocate pools, do the mapping, set up snap clones mount vols, etc.
They're running a small Brocade SAN.
Also stressed that IBM service has been incredible. "Best support services in the market. You call and get a live person - when does that happen?"
He said his advice would be to make sure you get the XIV A-team. Very informed and helpful.
Bottom line...all the things everyone says are good about XIV this guy confirmed. Simplicity, ease of management, 'good enough' performance.
Posted By:David Vellante| Thu Mar 11, 2010 04:44
-
thanks for the feedback David, we would like to the person, kindly share with us his mail id and phone number if possible, it shall be of great help to us
Posted By:kovid ranjan| Fri Mar 12, 2010 05:53
-
Hi Kovid - I have made an email introduction to you. Good luck and as always, please let us know if we can help in any way.
Posted By:David Vellante| Fri Mar 12, 2010 10:19
-
Hi Kovid,
My name is Roman Gast. I am working in HP’s SAP Engineering team out of Walldorf. We are responsible for qualifying HP storage solutions for and with SAP. If you feel you need to talk as well to an HP customer running SAP in a virtualized DT configuration beyond a metropolitan distance, please have your HP pre-sales contacting our group. I am confident that we will find a reference customer in your region.
Best regards,
roman
Posted By:roman gast| Sat Mar 13, 2010 04:38
-
Thanks for the help, I shall come back to
you
Posted By:kovid ranjan| Sun Mar 14, 2010 11:45
-
Hi Kovid and all....HP's Calvin Zito provided some links to EVA material in an SAP environment (thanks Calvin). I've posted these on the main page at the bottom under references. I have additional SAP/EVA material on migration, backup and windows configurations if anyone is interested just let me know and I'll post those as well.
Posted By:David Vellante| Wed Apr 21, 2010 07:57