Supposing that all data is in RAM, that's a huge and expensive machine.
Fortunately in most applications, you don't need to keep all your data in memory but only your live / active data.
Cassandra is able to retrieve automatically data from HD to RAM and back when the entry is missing from memory or getting "cold" respectively. You might compare Cassandra as a application level cache, where entries are account rows and cache hits/misses are referring to data already in memory or on the cassandra filesystem on disk.
So in terms of sizing:
- HDD is dimensioned for the total dataset
- RAM is dimensioned in order to reduce "cache misses"
So talking about RAM: You only need to keep enough data in memory in order to avoid unecessary refetches from disk. It's very application depended. I would suggest to run some benchmarking to veryfy how many many active sessions you get per day wrt to the total amount of sessions you have stored on the system. This applies well if your system is read dominated and reads have high locality. Check also this thread for further inspiration http://stackoverflow.com/questions/4924978/cache-design-question
This ratio of live data vs total data determines the RAM requirements for your system. Essentially, it's a tradeoff of cassandra misses vs RAM costs. Similar considerations - at a different level - apply to cpu cache design.