Cassandra - аппаратное планирование
И SBS 2003 и 2008 SBS требуют, чтобы они были единственным SBS в организации и домене. SBS 2008 и 2003 SBS также создают их собственные домены и не разрешают Вам присоединяться к ним как рядовой сервер любых других доменов.
Таким образом, я не знаю, были ли Вы планированием наличия их работающий в том же домене или лесу, но если Вы были, затем это не будет возможным, лицензируя мудрый или физически.
Учитывая, что первое предложение (Что они - только один SBS на организацию) я предположил бы, что это будет что-то вроде нет - нет.
В-третьих, 2008 CALs может быть понижен до 2003 CALs (но Вы утрачиваете право использовать лицензии 2008 года), но лицензии 2003 года автоматически не обновлены до 2008 (если у Вас нет Гарантированного программного обеспечения), таким образом, Вам будет нужен новый CALs там также. Это - исключение, если Вы выполняете SBS 2003 R2, но это истекло на полпути до 2009.
Вы найдете много вопросов и ответов относительно лицензирования SBS (который может быть минным полем, особенно с премиальным выпуском), здесь.
Если вы равномерно распределите свои 5 ТБ данных на 5 серверов, на каждом сервере будет размещаться 1 ТБ данных. Из-за необходимости уплотнения каждому серверу потребуется 2 ТБ дискового пространства (в худшем случае для сжатия потребуется вдвое больше места на диске, чем у вас есть данных), что означает всего 10 ТБ в вашем кластере.
Случай выше здесь вы храните только одну реплику ваших данных в кластере. В этом случае, если сервер выйдет из строя, пятая часть ваших данных будет недоступна. Если вы хотите сохранить 2 реплики ваших данных в кластере, каждому узлу потребуется 4 ТБ дискового пространства, что означает 20 ТБ всего в вашем кластере.
Предлагаемое cassandra дисковое пространство на узел для обеспечения производительности составляет 1/2 терабайта, поэтому, если вы не хотите ждать очень долгого сжатия и очень долгого времени отображения / сокращения, вам следует переосмыслить, сколько машин необходимо.
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 when the entry is missing from memory. Conversely, when the record in not accesses is expelled from memory ("cold" data). You might compare Cassandra as an application level cache, where entries are account rows. Cache hits/misses in this case can be interpreted as records on the cassandra filesystem disk which have to be brought back in memory.
So in terms of sizing:
- HDD is dimensioned for the total dataset
- RAM is dimensioned in order to reduce "cache misses"
- Replication factor affects throughput and resiliency
So talking about RAM: You only need to keep enough data in memory in order to avoid unnecessary re-fetch from disk. It's very application dependent. I would suggest to run some benchmarking to verify how 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 exhibit temporal locality.
Check also this thread for further inspiration https://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.