I do highly-available Drupal for a living as an engineer at BlackMesh. As TomTom said, anything 99.9% ("three nines") and below is very straightforward.
Getting above 99.9% is easy if you want to spend money adding servers and load balancers and all that jazz. If you don't, though, there might be another way. I'd rearchitect your solution into two machines, and spend the savings from the lack of the third machine on making the other two more powerful. Perhaps counter-intuitively, you can also seriously consider sacrificing some level of redundancy, as well—for example, you might forgo a secondary power supply on a physical machine in favor of simply connecting each of these two machines to different buses.
Anyway, what you do with these two machines is set them up in a proper cluster. Have HA IP addresses that fail back and forth between them.* Machine one is the default Web machine, running Drupal. Machine two is the default DB and LRS machine. In the event of a failure, the addresses move such that the remaining machine takes the full load. For MySQL, this will require master-master replication; for Drupal, it will require syncing of the DocRoot (paying special attention to the "files" directory); for your LRS, it may necessitate a manual failover process.
With this type of configuration, with decent hardware, good power, etc., you should expect to see five nines (99.999%) of OS uptime (which works out to about five minutes of downtime per year), and close to that number in terms of Layer 7 availability. Since you said you'd need to justify the numbers you came up with, five nines presumes a shared-nothing environment, and is simply the failure rate of an individual server (1.0-99.75%==0.25%) squared to represent the probability of two servers going offline at once (1.0-0.25%*0.25%==99.999375%), with a bit of a fudge factor.
Lastly, I should note that these sorts of SLA's are a bit of a red herring. See https://serverfault.com/a/161141/46760 for my thoughts on this matter. The reality is, you'll lose DAYS of functional availability due to someone fat-fingering a click on the Drupal admin account (or something similar) over the life of this solution. Setting up good change control and similar processes should be given equal billing, if not first billing, over hardware redundancy discussions.
*: n.b. There is a potential for split-brain in any cluster with an even number of members. One of the better ways to lower the probability is to route health check traffic over the public interfaces. If you want to be really paranoid, look into STONITH over serial.
