Clustering is generally used as a solution to performance, however my interpretation of what you've written is that its the size of the database which is the problem?
Using a NoSQL database is usually done for performance reasons (MySQL replication is simple to set up - so there's not a lot of difference in terms of availabiltiy) But you loose out on a HUGE amount of functionality. Hadoop is not going to solve your data volume problems, and may mean you've got a LOT of code to rewrite.
How you manage data volumes is vastly dependent on the nature of the application and the data - can you delete old data? Can you migrate it offline? Can you consolidate old data?
The ideal solution for us is when the HDD reaches its limit, we will just add another HDD on the machine then MySQL will recognize it as one
While you can simply add disk as a RAID-0 or JBOD array, this is a very messy practice - you're going from a single point of failure to multiple points of failure.
Similarly you can mount the disk and migrate individual table files over (using symlinks from the original locations) but this presupposes that you are not running a single-file innodb backend. This is just as bad as using RAID-0/JBOD.
For a transactional DBMS, mirroring (RAID-1) offers massive performance benefits - but does not increase storage volumes. So I would recommend planning a jump in storage from 1 to 4 drives (configured as a mirrored pair of strip sets).