Page 1 of 2 12 LastLast
Results 1 to 40 of 54
  1. #1
    Join Date
    Jun 2003
    Location
    Los Angeles, CA
    Posts
    1,512

    OnApp Alternatives

    Having too many issues with OnApp, anyone have any recommendations for alternatives?
    Psychz Networks - Dedicated Servers, Co-location | GigePipe - High Bandwidth Servers | PhotonVPS - SSD Cloud
    True Layer 7 DDoS Mitigation | BGP Optimized by Noction Intelligent Routing | Asia-Pacific Low Latency Routes
    Los Angeles, CA (US West) | Dallas, TX (US East) | Ashburn, VA (US East)

  2. #2
    We use OpenNebula and we're quite happy with it. It is much more comprehensive enterprise platform. It could be used for provisioning of a physical, bare metal servers as well.
    Host Color Cloud Servers & Dedicated Hosting & European Infrastructure Hosting
    U.S. Data center 90 miles from Chicago
    Network ★ AS46873 Level 3, Cogent, Hurricane Electric, Retn.net, Midwest Peering
    24/7 Support 1-574-367-2393; Skype: HostColor

  3. #3
    Join Date
    Nov 2012
    Location
    Toronto
    Posts
    426
    What type of issues?
    Andrew Wataszko - [email protected]
    Quartet Service Inc
    Cloud Services | Support Services | Technology Management Programs

  4. #4
    Join Date
    Feb 2011
    Location
    Denver, CO
    Posts
    124
    I'm interested to hear what issues you have run into as well.
    Mike Kauspedas - GearHost
    PaaS Cloud for .NET and PHP Developers
    Publish using Git, Visual Studio 2013 or FTP. Signup - No credit card required
    Personal blog www.mikesaysmeh.com

  5. #5
    Join Date
    May 2008
    Location
    Cusco Perú
    Posts
    548
    See the topics webhostingtalk.

    https://www.google.com/search?q=site...alternative%27

    precise and related subject.
    http://lowendtalk.com/discussion/892...ative-to-onapp

    Always good to search by date and vs.

    product vs other
    Product keyword 2014

    searh with yandex.ru, baidu and others.

  6. #6
    Join Date
    Oct 2001
    Location
    Ohio
    Posts
    8,299
    Quote Originally Posted by Profuse-Jimmy View Post
    Having too many issues with OnApp, anyone have any recommendations for alternatives?
    Jimmy,

    Sorry to hear that you're having problems. I will take a look through your ticket history with our team tomorrow morning, and have our guys follow up with you and explain what we can do to make things right.

    I'll be in touch as soon as possible.

  7. #7
    Join Date
    Apr 2011
    Posts
    112
    For more sophisticated cloud deployments, i would suggest CloudStack and/or OpenStack. They both have very advanced networking features and many other cool things which can't be done with OnApp. Also, if you have budget you can do VMware deployment.

  8. #8
    Join Date
    Sep 2005
    Location
    London
    Posts
    2,404
    Quote Originally Posted by Profuse-Jimmy View Post
    Having too many issues with OnApp, anyone have any recommendations for alternatives?
    are your issues related to Storage or is it the core platform that you are having problems with?
    Ditlev Bredahl. CEO,
    OnApp.com & SolusVM.com + Cloud.net & CDN.net

  9. #9
    Join Date
    Jun 2003
    Location
    Los Angeles, CA
    Posts
    1,512
    Quote Originally Posted by eming View Post
    are your issues related to Storage or is it the core platform that you are having problems with?
    We're working with Julian / James to see if we can get these issues squared away.
    Psychz Networks - Dedicated Servers, Co-location | GigePipe - High Bandwidth Servers | PhotonVPS - SSD Cloud
    True Layer 7 DDoS Mitigation | BGP Optimized by Noction Intelligent Routing | Asia-Pacific Low Latency Routes
    Los Angeles, CA (US West) | Dallas, TX (US East) | Ashburn, VA (US East)

  10. #10
    Do you mind sharing what the issues you're having are?

    We were about to sign with OnApp but I'm very skeptical about several aspects of their offering...

    Quote Originally Posted by Profuse-Jimmy View Post
    Having too many issues with OnApp, anyone have any recommendations for alternatives?
    BHost - Linux VPS and Cloud
    Fremont, CA | London, UK | Amsterdam, Netherlands
    Homepage - www.BHost.net
    Reviews - www.BHost.net/reviews

  11. #11
    Join Date
    Apr 2011
    Posts
    112
    Ask for free, managed test deployment for testing purpose before contract sign, it will help you to decide if OnApp fulfills your requirements.
    If you can't get free test deployment, then you can try OnApp free version with 16 core limit. But it is very hard to first users to configure it correctly. As as i know, free installation comes with no support.

  12. #12
    Also you can't test OnApp storage without signing up with them, and this is where the majority of my concern lies.

    Quote Originally Posted by RONIS View Post
    Ask for free, managed test deployment for testing purpose before contract sign, it will help you to decide if OnApp fulfills your requirements.
    If you can't get free test deployment, then you can try OnApp free version with 16 core limit. But it is very hard to first users to configure it correctly. As as i know, free installation comes with no support.
    BHost - Linux VPS and Cloud
    Fremont, CA | London, UK | Amsterdam, Netherlands
    Homepage - www.BHost.net
    Reviews - www.BHost.net/reviews

  13. #13
    Join Date
    Feb 2011
    Location
    Denver, CO
    Posts
    124
    If u ask they will give u a trial but we are signed up and paying. We're testing before deployment and integrating with our custom control panel.

  14. #14
    Join Date
    Sep 2005
    Location
    London
    Posts
    2,404
    Quote Originally Posted by bhost-limited View Post
    Also you can't test OnApp storage without signing up with them, and this is where the majority of my concern lies.
    Normally my team will help out and get you the licenses needed to throughly test OnApp. If not, ping me.
    Generally we prefer to do the first few installs with our clients (we do not charge for this), especially when storage is a part of the solution.

    OnApp Storage is a great platform, but by no means trivial to deploy. Most of the issues we see are related to misconfigs somewhere in the infrastructure.

    Feel free to ping me ([email protected]) if you've got questions or if I can help in any way.


    D
    Ditlev Bredahl. CEO,
    OnApp.com & SolusVM.com + Cloud.net & CDN.net

  15. #15
    Join Date
    Feb 2011
    Location
    Denver, CO
    Posts
    124
    Eh, it's not that hard to setup. I have very basic linux knowledge and was able to do it. There was an issue with DHCP an ********t but last time I installed 3.1 it worked fine. And the fix was simply copying the dhcp config file to the correct location. There's some network setup but for testing just keep it really simple and use two different switches. I was using basic 1Gb desktop switches.
    Mike Kauspedas - GearHost
    PaaS Cloud for .NET and PHP Developers
    Publish using Git, Visual Studio 2013 or FTP. Signup - No credit card required
    Personal blog www.mikesaysmeh.com

  16. #16
    Only issue we see with OnApp is the DMMP. By virtualizing the disks you add another layer of complexity and more creative ways to max out tcp buffers. With so much data flying around on the storage network, server kernels (both the node and the virtualized disks), NICs, and switches run into buffer limits/issues. It's easy to argue that it's a very redundant way of doing the storage, but it's one of the slowest ways of doing it and complex.

    We have spent months trying to optimize the kernel buffers on all the HyperVisors, and containers that run the disks. The more stripes and redundancy you have in your OnApp Storage, the more it amplifies this tcp buffer issues. Which explains why people with 1-2 disks get great performance, but when you add 3+ hypervisors with 8 disks spread around (4 stripes, 2 replicas) the performance is AWFUL! This is no fault to network, but the way OnApp DMMP virtualizes the disks and slams the hypervisors tcp buffers and the receiving hypervisors buffers.

    I hope in the future OnApp ditches virtualizing the disks (no more issues of buffers being slammed) and just have the host node take care of the disks. I know this will never happen, since they tout how independent each disk is and how it's a self containing unit.

    We have been playing around with OnApp Storage since it was released. Yesterday we had data corruption due to the storage API locking up. This has happened 3 times, about once a month. It corrupts all of the VM's associated to the HyperVisor where the disk is. FSCK on the linux servers typically fixes the corruption, but Windows servers are typically shot and un-recoverable. We have been told this was fixed in OnApp 3.2, if it happens again we are going to go the typical SAN route instead and let other people beta test this for a year like we did.

    We are going to upgrade to v3.2 after the Windows Backup bug is fixed. It's been a long year using OnApp Storage. Everything else has been great, but the cloud platform is only as strong as the Storage infrastructure which has been scary to deal with and frightening seeing 20-40 corrupt VM's from it.


    EDIT: For those wondering, we use EX4550 switches for the storage network. 2x 10Gig RR Bond to each HyperVisor.

  17. #17
    Join Date
    Feb 2011
    Location
    Denver, CO
    Posts
    124
    Thanks for the info, this helping a lot with our own decision process. Sorry for the bad experience but again, thanks for sharing.
    Mike Kauspedas - GearHost
    PaaS Cloud for .NET and PHP Developers
    Publish using Git, Visual Studio 2013 or FTP. Signup - No credit card required
    Personal blog www.mikesaysmeh.com

  18. #18
    Thanks for the feedback, let me join the discussion with a few comments

    Quote Originally Posted by CloudVZ View Post
    Only issue we see with OnApp is the DMMP. By virtualizing the disks you add another layer of complexity and more creative ways to max out tcp buffers. With so much data flying around on the storage network, server kernels (both the node and the virtualized disks), NICs, and switches run into buffer limits/issues. It's easy to argue that it's a very redundant way of doing the storage, but it's one of the slowest ways of doing it and complex.

    We have spent months trying to optimize the kernel buffers on all the HyperVisors, and containers that run the disks. The more stripes and redundancy you have in your OnApp Storage, the more it amplifies this tcp buffer issues. Which explains why people with 1-2 disks get great performance, but when you add 3+ hypervisors with 8 disks spread around (4 stripes, 2 replicas) the performance is AWFUL! This is no fault to network, but the way OnApp DMMP virtualizes the disks and slams the hypervisors tcp buffers and the receiving hypervisors buffers.
    This is true if you deploy your cloud and storage infrastructure as 2 independent components in a traditional centralised SAN model. Remember, however that OnApp IS is designed as a converged hardware solution. The real advantage of the architecture comes into play as you co-locate the VMs directly on HVs with local copies of data. The network is always likely to be a bottleneck for the forseeable future compared with raw disk IO speeds and for this reason alone a converged architecture will give you far better scale and performance as you scale from 3 HVs to 30HVs and beyond! This is something that quickly becomes unaffordable with a traditional SAN deployment model.

    Quote Originally Posted by CloudVZ View Post
    I hope in the future OnApp ditches virtualizing the disks (no more issues of buffers being slammed) and just have the host node take care of the disks. I know this will never happen, since they tout how independent each disk is and how it's a self containing unit.
    I disagree that handling drive IO access via independent controllers is just adding buffering complexity, it actually provides far greater scope to handle independent disk IO queues for co-located VM customers with different performance requirements using the same converged hardware. This is precisely how you can maintain performance isolation of the local storage access from other VM processes that are executing on the same servers.

    Quote Originally Posted by CloudVZ View Post
    We have been playing around with OnApp Storage since it was released. Yesterday we had data corruption due to the storage API locking up. This has happened 3 times, about once a month. It corrupts all of the VM's associated to the HyperVisor where the disk is. FSCK on the linux servers typically fixes the corruption, but Windows servers are typically shot and un-recoverable. We have been told this was fixed in OnApp 3.2, if it happens again we are going to go the typical SAN route instead and let other people beta test this for a year like we did.
    I will be more than happy to help you review this issue you're describing as we take reports such as this extremely seriously. For your info, the storageAPI is purely a control path component and has nothing to do with the raw data paths. Disk content getting corrupt can only happen if copies get out of synch and are somehow forced to get back in synch, e.g. to workaround a control path access issue. Please ping me directly via email and I'll check into it personally.

    We really do appreciate the support and patience that all users of the OnApp Integrated SAN have shown. I totally accept that there have been usability challenges and bugs in the early releases, but I am personally convinced that this is exactly the right way to build scalable cloud architecture, and really encourage everyone to give the 3.2 platform a try!

    Quote Originally Posted by CloudVZ View Post
    We are going to upgrade to v3.2 after the Windows Backup bug is fixed. It's been a long year using OnApp Storage. Everything else has been great, but the cloud platform is only as strong as the Storage infrastructure which has been scary to deal with and frightening seeing 20-40 corrupt VM's from it.
    Totally agree, and I strongly encourage you to upgrade to the latest version.

    Julian
    [OnApp storage platform architect]

  19. #19
    Join Date
    Apr 2011
    Posts
    40
    Quote Originally Posted by CloudVZ View Post

    EDIT: For those wondering, we use EX4550 switches for the storage network. 2x 10Gig RR Bond to each HyperVisor.
    Can you say how you have configured the bonding on the switches? Or do you have bonding configured at all on the switch? Just asking because I think the only option on the switch is to use 802.3ad.

  20. #20
    Join Date
    Apr 2011
    Posts
    112
    AFAIK, RR bonding is switch independent bonding mode.

  21. #21
    Join Date
    Jun 2013
    Posts
    60
    Quote Originally Posted by Doublepush View Post
    Can you say how you have configured the bonding on the switches? Or do you have bonding configured at all on the switch? Just asking because I think the only option on the switch is to use 802.3ad.
    Yes, that is what we've done. Need to spread NIC's out over the (untagged VLAN ports) on the switch unless the switch supports RR like this otherwise you get ports flapping up and down. Apparently onApp are working on a list of recommended switches for use with it which will make life a lot easier, but currently, as far as I'm aware, this list doesn't exist or if it does it isn't public.

  22. #22
    Join Date
    Jun 2013
    Posts
    60
    Quote Originally Posted by jc_storage View Post
    We really do appreciate the support and patience that all users of the OnApp Integrated SAN have shown. I totally accept that there have been usability challenges and bugs in the early releases, but I am personally convinced that this is exactly the right way to build scalable cloud architecture, and really encourage everyone to give the 3.2 platform a try!


    Totally agree, and I strongly encourage you to upgrade to the latest version.

    Julian
    [OnApp storage platform architect]
    I thought from the release notes that the improvements in backups were only for Linux systems not windows ones? Can you confirm if the fix does include windows systems?

  23. #23
    Join Date
    Sep 2005
    Location
    London
    Posts
    2,404
    Quote Originally Posted by CloudVZ View Post
    Only issue we see with OnApp is the DMMP. By virtualizing the disks you add another layer of complexity and more creative ways to max out tcp buffers. With so much data flying around on the storage network, server kernels (both the node and the virtualized disks), NICs, and switches run into buffer limits/issues. It's easy to argue that it's a very redundant way of doing the storage, but it's one of the slowest ways of doing it and complex.

    We have spent months trying to optimize the kernel buffers on all the HyperVisors, and containers that run the disks. The more stripes and redundancy you have in your OnApp Storage, the more it amplifies this tcp buffer issues. Which explains why people with 1-2 disks get great performance, but when you add 3+ hypervisors with 8 disks spread around (4 stripes, 2 replicas) the performance is AWFUL! This is no fault to network, but the way OnApp DMMP virtualizes the disks and slams the hypervisors tcp buffers and the receiving hypervisors buffers.

    I hope in the future OnApp ditches virtualizing the disks (no more issues of buffers being slammed) and just have the host node take care of the disks. I know this will never happen, since they tout how independent each disk is and how it's a self containing unit.

    We have been playing around with OnApp Storage since it was released. Yesterday we had data corruption due to the storage API locking up. This has happened 3 times, about once a month. It corrupts all of the VM's associated to the HyperVisor where the disk is. FSCK on the linux servers typically fixes the corruption, but Windows servers are typically shot and un-recoverable. We have been told this was fixed in OnApp 3.2, if it happens again we are going to go the typical SAN route instead and let other people beta test this for a year like we did.

    We are going to upgrade to v3.2 after the Windows Backup bug is fixed. It's been a long year using OnApp Storage. Everything else has been great, but the cloud platform is only as strong as the Storage infrastructure which has been scary to deal with and frightening seeing 20-40 corrupt VM's from it.


    EDIT: For those wondering, we use EX4550 switches for the storage network. 2x 10Gig RR Bond to each HyperVisor.
    Quick question: Are you distributing the storage drives inside the hypervisors, or have you setup a central set of servers for storage, with no VM's on them?


    D
    Ditlev Bredahl. CEO,
    OnApp.com & SolusVM.com + Cloud.net & CDN.net

  24. #24
    Quote Originally Posted by eming View Post
    Quick question: Are you distributing the storage drives inside the hypervisors, or have you setup a central set of servers for storage, with no VM's on them?


    D
    We setup separate HV's only for storage. However, we have been pretty successful in tuning this to work very well.

    This issue we are describing doesn't matter how you setup your storage. The write is still done off the HV with the data if you are utilizing replications. We have people PM'ing us all time for help fine tuning their storage network since this issue is not centralized to our setup. The way it works, it doesn't matter if all the storage is on separate HV's or local. Grant it, reads may be faster with local storage, but writes still suffer. We kind of gave up on submitting tickets and explaining this and showing it, since we have a pretty firm grasp on getting the speeds we want now. There is enough people now to submit tickets regarding any OnApp Storage issues, that we no longer have to do it. I just don't like how we had to spend nearly a year figuring out how to use OnApp Storage.

    I believe the memory needed is based on how many VM's you are going to place on your HyperVisors. 2GB is not nearly enough memory for HV's if there is 20+ VM's placed on it. DMMP will saturate the default tcp memory buffers, they must be increased.

    Let me be clear, that the only "issue" now is the lack of documentation, and the time and effort it took to to get OnApp Storage working how we want it.

    The only real issue other than speed, is the storage getting locked up and corrupting our VM's. However, there is no reason to dwell on that since we were informed it was fixed in v3.2. It's unfortunately it has happened to us several times and not knowing it was a bug in OnApp....we spent a lot of time looking internally for an issue.
    Cloud IaaS Solutions Provider - www.CloudVZ.com
    SSD SANs | High IOPs | Public & Private Cloud
    Solutions | Content Delivery Network
    Create your virtual datacenter in seconds!

  25. #25
    Join Date
    Sep 2005
    Location
    London
    Posts
    2,404
    Quote Originally Posted by CloudVZ View Post
    We setup separate HV's only for storage. However, we have been pretty successful in tuning this to work very well.

    This issue we are describing doesn't matter how you setup your storage. The write is still done off the HV with the data if you are utilizing replications. We have people PM'ing us all time for help fine tuning their storage network since this issue is not centralized to our setup. The way it works, it doesn't matter if all the storage is on separate HV's or local. Grant it, reads may be faster with local storage, but writes still suffer. We kind of gave up on submitting tickets and explaining this and showing it, since we have a pretty firm grasp on getting the speeds we want now. There is enough people now to submit tickets regarding any OnApp Storage issues, that we no longer have to do it. I just don't like how we had to spend nearly a year figuring out how to use OnApp Storage.

    I believe the memory needed is based on how many VM's you are going to place on your HyperVisors. 2GB is not nearly enough memory for HV's if there is 20+ VM's placed on it. DMMP will saturate the default tcp memory buffers, they must be increased.

    Let me be clear, that the only "issue" now is the lack of documentation, and the time and effort it took to to get OnApp Storage working how we want it.

    The only real issue other than speed, is the storage getting locked up and corrupting our VM's. However, there is no reason to dwell on that since we were informed it was fixed in v3.2. It's unfortunately it has happened to us several times and not knowing it was a bug in OnApp....we spent a lot of time looking internally for an issue.
    Thanks for clearing that up - it's interesting that it's actually performing for you.

    It's absolutely not how the OnApp storage platform is designed to be deployed. And we would have no documentation or internal support expertise to back such a deployment up.


    D
    Ditlev Bredahl. CEO,
    OnApp.com & SolusVM.com + Cloud.net & CDN.net

  26. #26
    Quote Originally Posted by eming View Post
    Thanks for clearing that up - it's interesting that it's actually performing for you.

    It's absolutely not how the OnApp storage platform is designed to be deployed. And we would have no documentation or internal support expertise to back such a deployment up.


    D
    Ugh....it doesn't matter how it's deployed. We spent a year showing that and other people on here showed it. A write is a write, and unless you have no replicas and a unstable environment then you wont have speed issues. A write operations has to go to a remote HV. When the vdisk is spread across the local HV, and 2 others, performance is around 50-90MB/s without optimization. These are not just our tests, but lots of people on these forums who have been trying it.

    Please stop saying it's only relevant to our case, as we have tons of PM's to prove otherwise. When you make a write, it writes to all replicas at once, not just locally...so it does depend on a storage somewhere else on the network. Trying to explain this to you was nearly impossible, so we had to bang our heads to figure out how we could improve performance. Which was entirely based on TCP buffers. Our speeds are no different than local reads/writes at this point. All I would recommend is that there should be more time educating your clients on possibly looking into TCP buffers when they have performance issues. After helping others who have the "Designed OnApp Storage", they see big improvements.

    I'm just explaining how it has been for us the last year using this. As of right now, I recommend everyone to give OnApp Storage a shot as of v3.2. With the right optimizations you will be impressed. It just was not easy for us getting to the point of v3.2, it has been a struggle.
    Cloud IaaS Solutions Provider - www.CloudVZ.com
    SSD SANs | High IOPs | Public & Private Cloud
    Solutions | Content Delivery Network
    Create your virtual datacenter in seconds!

  27. #27
    Join Date
    Feb 2011
    Location
    Denver, CO
    Posts
    124
    Quote Originally Posted by CloudVZ View Post
    I'm just explaining how it has been for us the last year using this. As of right now, I recommend everyone to give OnApp Storage a shot as of v3.2. With the right optimizations you will be impressed. It just was not easy for us getting to the point of v3.2, it has been a struggle.
    If you were starting right now with 3.2 knowing what you know about IS would you still choose to go IS instead of a SAN?
    Mike Kauspedas - GearHost
    PaaS Cloud for .NET and PHP Developers
    Publish using Git, Visual Studio 2013 or FTP. Signup - No credit card required
    Personal blog www.mikesaysmeh.com

  28. #28
    Quote Originally Posted by ghMike View Post
    If you were starting right now with 3.2 knowing what you know about IS would you still choose to go IS instead of a SAN?
    Yes. The performance we are now getting is up to par now, and for the price it makes no sense at this time to get SAN's that cost $50K-$150K. We rather invest that on the network and HyperVisors. It just took a lot of time figuring out how much memory was needed and where, and what to optimize.
    Cloud IaaS Solutions Provider - www.CloudVZ.com
    SSD SANs | High IOPs | Public & Private Cloud
    Solutions | Content Delivery Network
    Create your virtual datacenter in seconds!

  29. #29
    Quote Originally Posted by CloudVZ View Post
    Ugh....it doesn't matter how it's deployed. We spent a year showing that and other people on here showed it. A write is a write, and unless you have no replicas and a unstable environment then you wont have speed issues. A write operations has to go to a remote HV. When the vdisk is spread across the local HV, and 2 others, performance is around 50-90MB/s without optimization. These are not just our tests, but lots of people on these forums who have been trying it.

    Please stop saying it's only relevant to our case, as we have tons of PM's to prove otherwise. When you make a write, it writes to all replicas at once, not just locally...so it does depend on a storage somewhere else on the network. Trying to explain this to you was nearly impossible, so we had to bang our heads to figure out how we could improve performance. Which was entirely based on TCP buffers. Our speeds are no different than local reads/writes at this point. All I would recommend is that there should be more time educating your clients on possibly looking into TCP buffers when they have performance issues. After helping others who have the "Designed OnApp Storage", they see big improvements.

    I'm just explaining how it has been for us the last year using this. As of right now, I recommend everyone to give OnApp Storage a shot as of v3.2. With the right optimizations you will be impressed. It just was not easy for us getting to the point of v3.2, it has been a struggle.
    Or OnApp could just default the sysctl tcp buffers to 16MB along with a few other tweaks on each of the hypervisors and save everyone the trouble.

    In addition, if you are running SSD's or SSD caching, try changing your default disk IO from cfq to deadline. cfq is great for spindle drives, but not great for SSD's, deadline gives a nice performance boost.

    We busy considering OnApp at the moment, but these forums seem plagued with people having headaches with the OnApp storage, yet I hardly see anyone complaining about OnAPP + traditional SAN. While I under the concept that OnApp storage is designed to grow infinitely, I do somehow suspect that it will hit a barrier when you have a lot of hypervisors and 1000/10 000 VM's all trying to replicate at the same time, I almost feel like you would be dos'ing your own storage network... But I have no way of testing this theory.

    We still debating Integrated storage or Active-Active ISCSI SAN.

  30. #30
    Join Date
    Aug 2011
    Location
    Dub,Lon,Dal,Chi,NY,LA
    Posts
    1,838
    Our evaluation is that right now, onapp storage shows fantastic promise, and we'll probably try it out in 6-12 months.

    Make sure you assigned at least 1 physical core and 8GB RAM to dom0 on your HVs in general - we used to assign 2GB, then 4GB and saw recurring issues. HTH
    dediserve www.dediserve.com
    Leading provider of enterprise SSD cloud platforms with 15 clouds in 3 regions
    Dublin, London, Amsterdam, Vienna, Frankfurt, New York, Chicago, Dallas, Los Angeles, Toronto, Singapore, Jakarta, Hong Kong, Sydney

  31. #31
    Join Date
    Aug 2000
    Location
    Sheffield, South Yorks
    Posts
    3,480
    A lot of this could be avoided by documentation. I have to say that the documentation for IS is incredibly poor, there are terminology clashes all over the place in it and the UI.

    Take for example replicas - in the documentation it calls them copies of your data, in the UI it calls them replicas - If I select 1 replica that means I only get 1 copy of the data, the term replica means a copy of the original, so 1 replica should actually mean 2 copies of the data (The original and the replica)! That's just a small example.

    There should be a lot more examples on tuning and allocating RAM to dom0, and to IS, as well as info on tuning TCP buffers etc. This would not only reduce the workload of support, it would also give a much better initial impression of the product when people deploy it if they can avoid the performance pitfalls from what is basically an unconfigured system when first installed.

    IS overall has been rushed out the door IMHO - You can't even remove a dead drive for goodness sake! It'll sit there for ever more cluttering up the UI. Same applies if you change a NIC out, the old ones still show up. These are all things that at some point will need doing in a live environment.

    These are things we've picked up in some basic testing, before we've even got on to more extensive testing of IS.

    Not up to the usual OnApp standard :/
    Karl Austin :: KDA Web Services Ltd.
    UK Business Hosting and Managed Servers - Hosting for Business Users :: 0800 5429 764
    Call us today and ask about our hosting solutions.

  32. #32

    *

    Quote Originally Posted by murmaiderz View Post
    Or OnApp could just default the sysctl tcp buffers to 16MB along with a few other tweaks on each of the hypervisors and save everyone the trouble.

    In addition, if you are running SSD's or SSD caching, try changing your default disk IO from cfq to deadline. cfq is great for spindle drives, but not great for SSD's, deadline gives a nice performance boost.

    We busy considering OnApp at the moment, but these forums seem plagued with people having headaches with the OnApp storage, yet I hardly see anyone complaining about OnAPP + traditional SAN. While I under the concept that OnApp storage is designed to grow infinitely, I do somehow suspect that it will hit a barrier when you have a lot of hypervisors and 1000/10 000 VM's all trying to replicate at the same time, I almost feel like you would be dos'ing your own storage network... But I have no way of testing this theory.

    We still debating Integrated storage or Active-Active ISCSI SAN.
    Excellent recommendations, but that is something OnApp may want to include in their ********t images so it doesn't reset after reboots.

    OnApp Storage has come a long way. We really have put it through the ringer and are now quite impressed. Disconnecting servers, pulling out drives, and the DMMP continued to work as expected.

    I know it may appear we gave it a hard time on here, but it was really to inform other users who have been PMing us trying to speed up their SAN network. It's important to explore and optimize your tcp buffers as it can make a 400-500% difference.

    Now that v3.2 is out, it is definitely a stable platform to use. We are excited to see more features roll out in the future for OnApp I.S.
    Cloud IaaS Solutions Provider - www.CloudVZ.com
    SSD SANs | High IOPs | Public & Private Cloud
    Solutions | Content Delivery Network
    Create your virtual datacenter in seconds!

  33. #33
    Join Date
    Nov 2012
    Location
    Toronto
    Posts
    426
    Quote Originally Posted by KDAWebServices View Post
    A lot of this could be avoided by documentation. I have to say that the documentation for IS is incredibly poor, there are terminology clashes all over the place in it and the UI.

    Take for example replicas - in the documentation it calls them copies of your data, in the UI it calls them replicas - If I select 1 replica that means I only get 1 copy of the data, the term replica means a copy of the original, so 1 replica should actually mean 2 copies of the data (The original and the replica)! That's just a small example.
    /
    This really confused me when I first installed IS. It's extremely unclear. 1 replica means you have one copy of it, meaning 1 "production" and no extra copy (replica). That means only one copy, no redundancy, why do they even offer that?. Super confusing. This should be simple, in plain terms as once you choose your configuration, theres no going back.

    Honestly, I find IS not very mature. It lacks a lot of basic features (such as removing a node). Do they really expect hosts to manually move vdisk by vdisk to another host? Another one is if a host goes offline, you run with a single copy unless you run a mass repair. I must be spoiled by the nice features of VMware.

    I will give them some credit, they are trying their best to provide a low cost solution. If you look at VMware's local storage solution, licensing starts around 5K and they have some pretty strict system requirements in terms of supported RAID configurations.
    Andrew Wataszko - [email protected]
    Quartet Service Inc
    Cloud Services | Support Services | Technology Management Programs

  34. #34
    I am really glad that the performance issues have been ironed out for you, I totally agree that it took some fairly detailed analysis and time to get properly to the bottom of it.

    Just to clarify a couple of points...

    Quote Originally Posted by CloudVZ View Post
    When you make a write, it writes to all replicas at once, not just locally...so it does depend on a storage somewhere else on the network.
    Not strictly true for an optimally placed VM. For a 2 copy Datastore where one of the copies is local you only have to replicate once over a remote path. For reads this significantly reduces the exposure to the InCast phenomenon which is the primary path that was affected here. It also of course reduces the amount of network traffic for writes.

    Quote Originally Posted by CloudVZ View Post
    Trying to explain this to you was nearly impossible, so we had to bang our heads to figure out how we could improve performance. Which was entirely based on TCP buffers. Our speeds are no different than local reads/writes at this point. All I would recommend is that there should be more time educating your clients on possibly looking into TCP buffers when they have performance issues. After helping others who have the "Designed OnApp Storage", they see big improvements.
    Just for additional info for others following the discussion - rather non-intuitively it turns out that the problem with TCP buffers over faster network infrastructure hitting the TCP incast issue (as was the case here) is that they must actually be smaller in size to ensure that bursts of packets don't hit the ingress port. However the buffering behaviour actually completely depends on the characteristics of the switch, such as enforcement of flow control, port buffer sizes etc.. So there is not really a single configuration fits all.

    Quote Originally Posted by CloudVZ View Post
    I'm just explaining how it has been for us the last year using this. As of right now, I recommend everyone to give OnApp Storage a shot as of v3.2. With the right optimizations you will be impressed. It just was not easy for us getting to the point of v3.2, it has been a struggle.
    Thats great feedback and thanks for the vote of confidence! We're really glad that it is working well now and we're very happy to provide advice to anyone on performance customisations on their IS deployments.

  35. #35
    Quote Originally Posted by Quartet-Andrew View Post
    This really confused me when I first installed IS. It's extremely unclear. 1 replica means you have one copy of it, meaning 1 "production" and no extra copy (replica). That means only one copy, no redundancy, why do they even offer that?. Super confusing. This should be simple, in plain terms as once you choose your configuration, theres no going back.
    Yep, totally agree. We are in the process of clarifying the terminology and documentation around all these items.

    Quote Originally Posted by Quartet-Andrew View Post
    Honestly, I find IS not very mature. It lacks a lot of basic features (such as removing a node). Do they really expect hosts to manually move vdisk by vdisk to another host? Another one is if a host goes offline, you run with a single copy unless you run a mass repair. I must be spoiled by the nice features of VMware.
    Totally fair comment, this has been a very CLI-based operation prior to the 3.1+ releases. Just for info now:

    - dynamic disk hotplug support is added now with 3.1+ onwards
    - mass vdisk repair support now provided through the IS diagnostics UI
    - automated disk content re-balancing support will be released very soon

  36. #36

    *

    Quote Originally Posted by jc_storage View Post
    Just for additional info for others following the discussion - rather non-intuitively it turns out that the problem with TCP buffers over faster network infrastructure hitting the TCP incast issue (as was the case here) is that they must actually be smaller in size to ensure that bursts of packets don't hit the ingress port. However the buffering behaviour actually completely depends on the characteristics of the switch, such as enforcement of flow control, port buffer sizes etc.. So there is not really a single configuration fits all.
    This is why we have been unable to tell people exactly what tcp buffer settings to use. The settings are very dependent on the amount of memory you have available for it, what the switch(es) can handle, and how the I.S. is setup. To much memory for the TCP buffers caused to much congestion, and to little caused to much congestion.

    Look forward to seeing more support for our type of setup though, as we focus on high density setups. It can work both ways, just our way took a bit more of work to deal with.
    Cloud IaaS Solutions Provider - www.CloudVZ.com
    SSD SANs | High IOPs | Public & Private Cloud
    Solutions | Content Delivery Network
    Create your virtual datacenter in seconds!

  37. #37
    Join Date
    Jul 2003
    Location
    Waterloo, Ontario
    Posts
    1,116
    We have been evaluating the OnApp cloud platform with their IS for some time now and we have seen a lot of people posting their issues with storage so we have been staying clear for the time being until everything is fixed.

    We have some I/O issues with AppLogic here and there but there are options in optimizing that and also removing nodes and migrating volumes from one node to another. Is this a feature with OnApp for migrating volumes at this time or is this a future enhancement?

    Having a local copy is definitely a huge benefit, we don't have that option with AppLogic at this time and it can impede on performance from time to time. When OnApp copies volumes onto another node, does it set a limit on the transfer rate? AppLogic does which is good in the sense that it does not bring down performance for the existing volumes and I'm wondering if OnApp has any built in controls to ensure IO does not take a huge hit while volumes are copied across the network. Can somebody comment on this?

    It's great to see everybody posting their feedback, I hope everything shapes up for everybody using OnApp!
    Right Servers Inc. - Fully Managed Cloud Servers in Canada. Join our White Labelled WHMCS Cloud VPS Reseller Program to become your own host!
    SSD Accelerated Cloud | cPanel/WHM | Softaculous | Idera Backups | Bitcoin & Litecoin Accepted

  38. #38
    Quote Originally Posted by Dedicatedone View Post
    We have been evaluating the OnApp cloud platform with their IS for some time now and we have seen a lot of people posting their issues with storage so we have been staying clear for the time being until everything is fixed.

    We have some I/O issues with AppLogic here and there but there are options in optimizing that and also removing nodes and migrating volumes from one node to another. Is this a feature with OnApp for migrating volumes at this time or is this a future enhancement?
    Yes, you can re-balance virtual disk content across drives on any HV of your choosing through the UI. The Datastore must be configured with redundancy so there's at least 2 copies of data.


    Quote Originally Posted by Dedicatedone View Post
    Having a local copy is definitely a huge benefit, we don't have that option with AppLogic at this time and it can impede on performance from time to time. When OnApp copies volumes onto another node, does it set a limit on the transfer rate? AppLogic does which is good in the sense that it does not bring down performance for the existing volumes and I'm wondering if OnApp has any built in controls to ensure IO does not take a huge hit while volumes are copied across the network. Can somebody comment on this?
    The copy/resynchronisation rate is reduced and always runs as a lower priority task when restoring content to a new replica. You should not notice any performance impact on other drives when migrating data between hypervisors.

    Quote Originally Posted by Dedicatedone View Post
    It's great to see everybody posting their feedback, I hope everything shapes up for everybody using OnApp!
    Thanks for the feedback, hope you get a chance to try out the storage platform!

  39. #39
    Join Date
    Jul 2004
    Location
    New York, NY
    Posts
    2,179
    Have said this for a long time. OnApp is for people who don't have the time to invest into a custom solution and want something that works for a medium-sized operation.

    If you want custom, invest in OpenStack or Cloudstack. The biggest plus right now for OnApp is that it makes cloud hosting more affordable for people, particularly those who don't want to spring for a complete SAN infrastructure. That said, overtime, you will find OnApp to be quite taxing on your margins
    ServGrid - www.servgrid.com - Affordable and Reliable SSD Cloud Solutions
    Premium 10G Network, 2(N+1) Powerplant and SSD Performance
    Web, Reseller, KVM VPS, Storage and Private Cloud Hosting
    Click here to see our SSD Benchmarks!

  40. #40
    Join Date
    Jul 2010
    Posts
    69
    Quote Originally Posted by The Broadband Man View Post
    Have said this for a long time. OnApp is for people who don't have the time to invest into a custom solution and want something that works for a medium-sized operation.

    If you want custom, invest in OpenStack or Cloudstack. The biggest plus right now for OnApp is that it makes cloud hosting more affordable for people, particularly those who don't want to spring for a complete SAN infrastructure. That said, overtime, you will find OnApp to be quite taxing on your margins
    When you say "you will find OnApp to be quite taxing on your margins" could you expand a little further on this?

    I've found that when OnApp customers grow and add more customers of their own they gain more revenue. As they grow, we don't increase per unit pricing so the margin shouldn't change at all.
    Caroline Paine
    Commercial Operations Manager @ www.onapp.com
    Inquisitive Foodie @ www.inquisitivefoodie.com

Page 1 of 2 12 LastLast

Similar Threads

  1. [FEATURED] OnApp Cloud: Hardware SAN v OnApp Storage (SANity)?
    By [email protected] in forum Colocation and Data Centers
    Replies: 212
    Last Post: 04-24-2013, 05:59 PM
  2. Alternatives to onApp and applogic
    By The Broadband Man in forum Dedicated Server
    Replies: 1
    Last Post: 06-26-2012, 12:51 PM
  3. /. Alternatives?
    By MattF in forum Web Hosting Lounge
    Replies: 5
    Last Post: 10-21-2004, 02:40 PM
  4. CC alternatives?
    By u4t2t in forum Running a Web Hosting Business
    Replies: 3
    Last Post: 12-02-2002, 08:32 AM
  5. alternatives?
    By km in forum Web Hosting
    Replies: 0
    Last Post: 10-23-2001, 06:16 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •