In my hard drive, information is stored on a physical chip, given an address, and stored, until retrieved. (...)
How is it addressed and retrieved?
In most clouds, using HTTP acces, parts of URL constitute the address. In the largest data cloud in existence, Amazon S3, URL may include the netloc to designate so-called "bucket" (like BUCKET.s3.amazon.com/PATH/KEY). Otherwise, the URL path is used (s3.amazon.com/BUCKET/PATH/KEY). There may be variations, such as RAX CloudFIles (probably 3rd largest after S3 and Azure) scheme of cf.com/v1/AUTH_tenant/PATH/KEY.
Inside the cloud, the address is typically split right away into a bucket, tenant, or equivalent, and the rest. This way useful segmentation may be maintained and the transparency is balanced with opaquity. For example, in S3 a bucket is always maintained within a certain datacenter and a user may guarantee bucket placement (in case of a terrorist attack or a natural disaster). A typical bucket gets churned through a database map function to produce necessay internal addresses (typically internal base URLs). Well, I think every cloud except Azure does that.
The PATH/KEY selector is fed into a DHT (a hash table) function that also takes care or things like redundancy or Erasure Coding for clouds that use that. In the end it produces trailing parts of internal URLs. They are smashed back together with the base URLs derived from buckets. There's a great variety of approaches of doing that. One simple way is to make something like:
bucket => tenant (token)
path => suffix/hash (several per. redundancy or EC)
for example, for cf.com/v1/path/key:
http://10.0.50.20/v1/object/790/e7f...1694790/146c07ef2479cedcd54c7c2af5cf3a80.data
(several of these on 10.0.50.20, 10.1.50.20, 10.3.50.20 etc. as per placement)
In some cases there boundary between (internal) bucket and the hashed paths is somewhat varying. In particular it's well known that S3 changes the prefix length depending how loaded a bucket is. It is called "sharding".
Once the internal URL hits the actual server, it is addressed in exactly the same way your Word document with a path is.
So the high level overview is mostly trivial. I am omitting a bunch, of course, for simplification.
The really interesting question, which makes or breaks a cloud, is how it deals with failures. In a large cloud one disk drive or node failure happens between every few seconds to every hour. So someone on your ops team usually starts his day by looking at the failure report and perhaps ordering reconfigurations, possibly swapping drives, shelves, or racks (in case fail-in-place is used, when rack falls below a certain threshold).
Once the failure is made official, manually or automatically, the cloud has to restore the redundancy. To that end, it starts an internal copying (using a version of internal URL above -- EC clouds such as Azure also perform the math necessary to reconstruct the data from fragments).
The trick is that the storage and retrieval have to continue with imperceptible disruption while all that is going on. Obviously the recovery competes with the normal access for the bandwidth. So it cannot consume too much, or users see a major degradation. But it cannot go too slow, or else consequent failures may impart availability or even durability. The balance is tricky to get right. Again, the way, say, S3 does it, is a closely guarded secret. Usually a certain scheduling or throttling system decides how many megabytes per second to shuffle for each replication unit. But sometimes it's an ops guy setting percentages, monitoring the cloud health, and adjusting as needed.
P.S. Come to think of it, it's amazing that cloud storage works at all.
