Bulk Feature Request :-)
I have some feature requests for you:
1. datacenter/rack awareness while replicate
2. Supporting multiple IPs per node
This way you just can use two or three NIC with different IPs per node and an own switch. You don't need to trunk the NIC and you don't need very expensive (!) high available switches. To cummincate you just send the data to a random IP of the target node. Then if one IP fails, just use one of the remaing IPs.
3. Allow different memory sized nodes to join.
Just put not so much data to the nodes with less data. This way you can add new nodes very easily and are free for future hardware changes. You can eliminate one node, put new ram to it or buy a new node with more ram and you are done.
4. Change from community to enterprise edition during runtime
5. Upgrade during runtime
Regarding to the upgrades, I can't do all these things while in production mode. Then I need to shutdown ALL servers as they can only work together if they have the same version.
If this is solved I could update one node after the other.
Maybe some will make it into one of the next versions.
Silas,
I have created Jira issues for your feature requests. Hopefully you will see some of these released this year.
Thanks
To follow up here Sila,
1 - This is a feature currently on our roadmap for support both intra-rack deployments as well as intra-data center deployments (tracked by http://jira.membase.org/browse/MB-3303)
2 - This is a nice feature, but would add significant complexity to the administration of Membase. We have a number of plans to improve upon our general clustering architecture and do away with the need to rely upon a specific IP address. As per this link (http://wiki.membase.org/display/membase/Using+Membase+in+the+Cloud) you can configure an individual node to identify itself via a hostname and then from an external system could control which IP address that hostname resolves to (in order to take care of the failover you are referring to).
3 - This is on our roadmap, though I don't have a solid timeframe for you (tracked by http://jira.membase.org/browse/MB-3310)
4 - This is not something we are likely to support. At the moment, the Community and Enterprise editions are very similar, but as time progresses they will diverge. We suggest that if you are going to be deploying in a production environment that you go with the Enterprise Edition and purchase a subscription from us. The Community edition does not go through as rigorous a QA process and is designed for testing and evaluation purposes.
5 - Upgrading during runtime is actually already a supported feature. There is one caveat dealing with upgrades from 1.6.0 because of some of its stability issues, but going forward we will support "rolling" upgrades (as you have described) wherever possible. There may be certain cases down the road where one version will be incompatible from the last, but this will be avoided as much as possible.
Thanks for your interest, please let us know how else we can help.
Perry
Hello,
I have additional suggestions/questions regarding the "support more than one NIC". You referred to the article "running membase in a cloud".
So I would set up some DNS servers that will answer to a dns request with:
10.1.0.1 cloudnode1
10.2.0.1 cloudnode1
10.3.0.1 cloudnode1
No when membase can't reach cloudnode1 via IP 10.1.0.1 it will try to use 10.2.0.1?
Will you do a new dns query for that?
Can I enter more than one DNS server for membase to use (So there is no SPOF)?
Silas, I'm not entirely sure how Membase will behave in this situation...it needs testing and I would certainly appreciate any information or feedback you can provide but I believe it should work the way you described.
As far as supplying multiple DNS servers, most (all?) operating systems support that and so anywhere you can install Membase you should be able to provide multiple DNS servers.
Perry
1 - This is a feature currently on our roadmap for support both intra-rack deployments as well as intra-data center deployments (tracked by http://jira.membase.org/browse/MB-3303)
...
Hi Perry
I've commented on the JIRA, but we view this as critical, since we use multiple virtual machines on large blade servers, which obviously then reside in a single rack as well. We have multiple blades in the environment, and can potentially host multiple blades in a single rack. We need to be able to ensure that replication does not occur between nodes on the same blade chassis (server), as well as between chassis in the same rack.
This is one of the issues preventing us from dropping our existing memcache + backing store model and migrating to couchbase as a permanent solution.
[I have merged this post into my first. I think in this thread the spam block was because I had a link to your release notes.]