The thing that'll tell you whether or not this is a good idea are three things:
- How your overall system behaves with one host missing data.
- How long it takes your hosting provider to replace dead disks.
- How your system behaves when it is in the process of resynching after a failed drive is replaced.
If your application accesses the Gluster data through a Gluster mount, it should stay up even if one node is down. However, if you're just using Gluster as a replication mechanism and configured your app-servers to use local storage (but replicated through Gluster), if one drive goes bad that one app-server may be still serving bad data. Obviously, I recommend using a Gluster mount whenever possible.
How long it takes your provider to replace dead hardware is a key concern. It tells you how long you have to live with a bad config, and how long you'll be experiencing any pain with point 1. 4-hour response is good, next-business-day is bad if it dies Friday night.
How your systems behave during resync is something you should really test. It depends a lot on how much data you've got to move from point-good to point-repaired. Your Gluster-mount I/O is likely to be bad during this time, so be sure you can withstand this state.
If you have all three states taken care of, R0 may be survivable for you. If your failed-state performance is unacceptable, you'll probably have to use a higher RAID level for your base Gluster bricks.