Unifi Controller Redundancy


  • T
    Beta Testers

    There should be away to provide controller redundancy - currently if the controller goes off line (hardware crash, or service shuts down), the access points go into autonomous mode.  This means guest networks end up either being locked out, or if access is  granted there are no limitations (other than restricted networks, etc).

    Please consider implementing the ability to have redundant controllers - a primary and secondary source. So that if the primary is offline, the AP contacts the secondary.  Synchronization of the primary and secondary controller should be easy enough to arrange.

    Duplicates:

    http://community.ubnt.com/t5/UniFi-Feature-Requests/Unifi-Controller-with-Simultaneous-Operation/idi-p/1165891

    http://community.ubnt.com/t5/UniFi-Feature-Requests/Unifi-Controller-Replication-amp-failover/idi-p/1232003


  • S
    Beta Testers

    That would be very handy. +1


  • R
    Beta Testers

    It's will be good for thick installations.


  • W
    Custom Avatar

    Yes, agreeing this would be an excellent feature.  Although I'm curious how autonomous mode is supposed to operate when using an external portal server.

    A deployment of mine, for example, had its UniFi controller crash when an unscheduled reboot prevented MongoDB from restarting.  However, The PHP-based captive portal (i.e. Apache and MySQL) were able to restart cleanly.  Do I understand current UniFi firmware on the APs will lock out the guest network if the controller goes down, even if the portal server remains up?


  • Beta Testers

    This would be so helpfull when we using Vouchers/Hotspot


  • F
    Beta Testers

    just an idea: for the time being, you could also achieve this with virtualising the controller and then use a "high availability" feature several virtualisation-vendors offer. As the controller uses relatively little resources, this should be doable.


  • B
    Beta Testers

    +25

    active standby or active active redundancy is a must for a large carrier class deployment.


  • Beta - EdgeRouter

    A large carrier class deployment would use some sort of clustered machines to install the software controller on, either physical, or virtual. Controller redundancy doesn't make sense, simply use a solid server harware, with a UPs, good switches, and you're good to go, your controller would never be offline. But if you're still worried, you can buy 2 servers, make a virtualization cluster using Microsoft Hyper-V server 2012R2, wich is free, and install the controller on a virtual machine, what's a better redundancy than that?


  • Beta - EdgeRouter

    Controller diversity DOES make complete sense, and in very large deployments with 10Gb+ requirements, is needed.


  • I
    Beta Testers

    I dunno about this, Rudency can be establish. we have vmware with cluster setup if one server goes down virtual server is still active i guess it is good for users with less productive enviroment.


  • T
    Beta Testers

    Several folks have suggested using virtualization for redundancy - I do not believe this is an adequate solution. In a virtualized or cluster environment the key would be to ensure that the actual database state of active clients is cleanly maintained - token / voucher access, statistics, etc.  Unless the databases are synched, a virtualization or cluster enviroment isn't going to help.

    The straight-forward solution is to have an active / standby server configuration with the active server updating the standby server databases at a frequent interval and a heartbeat or keepalive connection betweent the two hosts.  The servers could be virtual machines (presumably on separate physical hosts), but two logically separate servers are required for full redundancy.

    In an enterprise class environment, this is going to be a critical feature set, particularly in enterprises with diverse geographical locations.


  • V
    Custom Avatar

    Yes, the best think is to use a virtualization strategy.


  • A
    Beta Testers

    It would be great to have controller redundancy.

    I suggest Primary controller IP and Secondary controller IP can be added to the SW.

    APs to switch between controller IPs if connectivity IP is lost (+1 minute), this will help to cutoff between servers or during SW upgrade.

    I understand that at transactional level it will drop all active sessios, billing, etc. But as first stage it will be good to have just a hard switch-over option.

    Server to server redundacy can be developed by using internal server services (options).

    Thanks


  • Beta Testers

    Idea:

    host 2 unifi controllers in the cloud.  Provision devices to a single DNS address put both hosts in there:

    unifi.provisioningserver.com DNS entry contains unifi1.provisioningserver.com and unifi2.povisioningserver.com.

    Now replicate mongodb between the two boxes and rsync the hotspot directories.

    This would work today, except that I'm not sure how device polling would be handled and where that is stored.  If that's in mongo, then great, if not then we would need to figure that out else each controller would show a bunch of missing APs.


  • Beta Testers

    Data in the MongoDB is only one of two items that needs to be recoverable. DB sync can be done for local-local and hosted-hosted solutions, but the tougher scenario is local-hosted, meaning one UniFi server on site and another at Amazon (for example), since the EC2 instance would typically host multiple sites and the on-site instance would only host one.

    Here's the second piece - the .unf file with AP names - if you can't restore a config from a single-site UniFi server to a multi-site server, you can't recover a server without a dedicated server. For local-hosted solutions that means losing your AP names, which (at least for us) include the locations of the APs.

    UniFi lacks any migration tools. Defaulting an AP and doing a new set-inform in SSH is a pain, but if we at least had a tool to import the .unf for a single site on a multi-site server we wouldn't have to have someone walk through the site to rename all the APs.


  • Beta - EdgeRouter

    UnwiredCity wrote:

    Data in the MongoDB is only one of two items that needs to be recoverable. DB sync can be done for local-local and hosted-hosted solutions, but the tougher scenario is local-hosted, meaning one UniFi server on site and another at Amazon (for example), since the EC2 instance would typically host multiple sites and the on-site instance would only host one.

    Here's the second piece - the .unf file with AP names - if you can't restore a config from a single-site UniFi server to a multi-site server, you can't recover a server without a dedicated server. For local-hosted solutions that means losing your AP names, which (at least for us) include the locations of the APs.

    UniFi lacks any migration tools. Defaulting an AP and doing a new set-inform in SSH is a pain, but if we at least had a tool to import the .unf for a single site on a multi-site server we wouldn't have to have someone walk through the site to rename all the APs.


    this isn't needed. You just need to migrate your APs from local controller to offisite(multi-site) controller one by one. This way you can always know wich AP you are migrating and manually replicate every configuration, including it's name. You can also simply get a list of all APs mac addresses and annotate all of it's settings prior to migration, that isn't so hard.


  • Beta Testers

    @R4V3R, yes thank you - that is the process. It's not so bad when you have 10. It's pretty miserable when you have close to 1000.


  • I
    Beta Testers

    I don't know, that it is 100% redundancy, but in UniFi, you can setup in ~/cfg/mgmt 3 UniFi controllers - and UniFi if can't connect with first, tryed second, but it works just when is UniFi starting (after reboot) - if it is connected, it doesn't works…


  • Beta Testers
    This post is deleted!

  • administrators

    placeholder


Posts 80Views 103
Log in to reply

Looks like your connection to Ubiquiti Networks Community was lost, please wait while we try to reconnect.