Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/12—Avoiding congestion; Recovering from congestion
  • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/06—Management of faults, events, alarms or notifications
  • H04L41/0695—Management of faults, events, alarms or notifications the faulty arrangement being the maintenance, administration or management system
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/085—Retrieval of network configuration; Tracking network configuration history
  • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
  • H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/0893—Assignment of logical groups to network elements
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
  • H04L67/1004—Server selection for load balancing
  • H04L67/1006—Server selection for load balancing with static server selection, e.g. the same server being selected for a specific client
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/04—Network management architectures or arrangements
  • H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
  • H04L67/1004—Server selection for load balancing
  • H04L67/101—Server selection for load balancing based on network conditions
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
  • H04L67/1004—Server selection for load balancing
  • H04L67/1021—Server selection for load balancing based on client or server locations
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
  • H04L67/1034—Reaction to server failures by a load balancer

Definitions

• This application is directed, in general, to device management server architectures and, more specifically, to a scalable distributed multicluster device management server architecture and a method of operating the same to carry out device management.
• Electronic devices e.g., computers, srnartphones, television "set-top” boxes and home and small business networking equipment, such as routers, gateways and modems
• the service providers e.g., telephone, wireless, cable and satellite television companies and Internet service providers
• DM device management
• the server architecture includes: (1) a plurality of manager clusters and (2) a dispatcher cluster coupled to the plurality of manager clusters and configured to: (2a) receive an initial contact from a device, (2b) assign the device to one manager cluster of the plurality of manager clusters, the one manager cluster becoming a home cluster for the device, (2c) cause data regarding the device to be transferred to the home cluster and (2d) cause the device thereafter to communicate directly with, and be managed by, the home cluster.
• the server architecture includes: (1) a plurality of manager clusters and (2) a dispatcher cluster coupled to the plurality of manager clusters and configured to: (2a) receive an initial contact from a device, (2b) register the device, (2c) configure at least some service parameters on the device, (2d) assign the device to one manager cluster of the plurality of manager clusters, the one manager cluster becoming a home cluster for the device, (2e) cause data regarding the device to be transferred to the home cluster and (2f) cause the device thereafter to communicate directly with, and be managed by, the home cluster .
• the method includes: (1) receiving an initial contact from a device into a dispatcher cluster, (2) employing the dispatcher cluster to assign the device to one manager cluster of a plurality of manager clusters, the one manager cluster becoming a home cluster for the device, (3) causing data regarding the device to be transferred to the home cluster and (4) causing the device thereafter to communicate directly with, and be managed by, the home cluster .
• FIG. 1 is a block diagram of one embodiment of a scalable distributed multicluster architecture
• FIG. 2 is a block diagram of one embodiment of a scalable distributed multicluster architecture with disaster recovery
• FIG. 3 is a block diagram of one embodiment of a scalable distributed multicluster architecture with dynamic load balancing
• FIG. 4 is a flow diagram of one embodiment of a method of managing devices using a scalable distributed multicluster architecture.
• DM systems manage devices over the Internet. These DM systems are somewhat scalable in the sense that they can function either with a single network server computer ("server") or a single cluster made up of a handful servers functioning as peers (i.e., "horizontally") sharing a common data store.
• the single server or cluster whichever the case may be, is responsible for handling all traffic that the DM system receives or generates, including bootstrapping traffic ⁇ traffic attendant to initializing devices), management traffic (e.g., traffic attendant to software updating, feature and service enabling and disabling and subscriber communication) and communication with operations support software (OSS) or business support software (BSS) .
• OSS operations support software
• BSS business support software
• the number of devices a particular service provider's DM system is tasked with managing generally increases over time, sometimes dramatically.
• the architecture manages home networking devices. In alternative embodiments, the architecture manages one or more of computers, small business networking devices, communication devices (such as smartphones) and set-top boxes. Other embodiments manage still other conventional or later-developed devices .
• a dispatcher cluster may be employed to decide how the management of devices can or should be allocated between or among multiple clusters.
• Each cluster can be scaled by adding more servers to it.
• Each cluster of servers can be administered without materially disrupting the performance and availability of other clusters. In some embodiments, each cluster of servers can be independently administered without disrupting the performance and availability of other clusters whatsoever.
• New clusters can be added without materially degrading the performance of the existing clusters. This is a particularly valuable capability when as existing clusters reach their saturation points. In some embodiments, new clusters can be added without degrading the performance of the existing clusters whatsoever.
• Service providers have some flexibility in deciding how the architecture can be adapted to their needs. For example, service providers can decide how the management of devices is to be allocated to multiple clusters (e.g., the management of television set-top boxes can be allocated to one cluster, the management of Voice-over-IP, or VoIP, devices can be allocated to another cluster, and the management of Digital Subscriber Line, or DSL, Internet gateway devices can be allocated to another cluster) . As another example, service providers can decide that management of devices should be allocated between or among clusters based on the geographical location of the devices ⁇ e.g., devices in an eastern zone that includes New York, Pennsylvania and Virginia can be managed by one clusters, and devices in a western zone that includes California, Oregon and Washington can be managed by another cluster) .
• Exceptionally large management loads (those detrimental to the performance of a particular cluster) and therefore dynamically reallocated to other clusters .
• excessive management loads caused by faulty devices, faulty or significant upgrades or faulty servers or interconnections in or to a particular cluster) can create a capacity bottleneck.
• some of that load can be transferred to other (e.g., secondary) clusters temporarily.
• a conventional load balancing strategy is employed for this purpose.
• FIG. 1 is a block diagram of one embodiment of a scalable distributed multicluster architecture 100.
• the architecture includes a dispatcher cluster 105 and manager clusters 1...N, e.g., a manager cluster 1 110, a manager cluster 2 115 and a manager cluster N 120.
• the dispatcher cluster 105 includes a bootstrap server 106, a plurality of management servers 107 and a data store 108.
• the bootstrap server 106 initializes the plurality of management servers 107 so they can cooperate to perform a particular function.
• the plurality of management servers 107 employ the data store 108 to perform the particular function.
• the particular function of the dispatcher cluster 105 includes assigning the management of particular devices to manager cluster 1
• manager cluster 2 115 manager cluster N 120.
• a data path 130 couples the dispatcher cluster 105 to such OSSs and/or BSSs 125 a particular service provider may employ.
• the OSSs and/or BSSs 125 may provide commands to the dispatcher cluster 105, e.g., to deploy an upgrade to device software or firmware or originate or terminate a particular service.
• the OSSs and/or BSSs 125 may also gather management data from the dispatcher cluster 105, e.g., to form a basis for billing or marketing efforts by the service provider.
• the OSSs and/or BSSs 125 are commercially available. Those skilled in the pertinent art understand how commercially available OSSs and BSSs may communicate with management systems .
• Manager cluster 1 110 includes a bootstrap server
• manager cluster 1 110 includes the management of particular devices according to assignments by the dispatcher cluster 105.
• manager cluster 2 115 includes a bootstrap server 116, a plurality of management servers 117 and a data store 118 that cooperate and function like manager cluster 1 110 to manage particular devices in accordance with assignments by the dispatcher cluster 105.
• manager cluster N 120 includes a bootstrap server, a plurality of management servers and a data store that cooperate and function like manager clusters 1 and 2 110, 115 to manage particular devices in accordance with assignments by the dispatcher cluster 105.
• the dispatcher cluster 105 and the manager clusters are coupled to the Internet 135 through which they are coupled to various examples of devices to be managed, including an Internet gateway device 140, a VoIP device 145 and a television set-top box 150.
• manager cluster 1 110, manager cluster 2 115 and manager cluster N 120 are geographically separated from one another, such that an environmental issue (e.g., fire, earthquake or power loss) that might adversely affect one manager cluster likely does not affect the other manager clusters.
• the dispatcher cluster 105 is geographically separated from all of the manager clusters 110, 115, 120.
• FIG. 1 represents this initial contact by, e.g., the Internet gateway device 140, the VoIP device 145 or the television set-top box 150, with respective arrows 155, 160, 165, 170.
• the illustrated embodiment of the dispatcher cluster 105 registers the device.
• the dispatcher cluster 105 also activates the device.
• the dispatcher cluster 105 configures only the most essential service parameters on the device.
• one embodiment of the dispatcher cluster 105 executes one or more configured business rules that, e.g., identify the type of device, the geographic location of the device or the subscriber to whom the device belongs or with whom the device should be associated. This identification culminates in a manager cluster being assigned with managing the device, which then becomes that device's "home cluster.”
• one embodiment of the dispatcher cluster 105 then causes data regarding the device (e.g., data essential to the managing of the device) to be transferred (e.g., copied) to the home cluster.
• FIG. 1 represents this transfer with the appropriate home cluster with respective arrows 175, 180.
• the illustrated embodiment of the dispatcher cluster 105 redirects the device to its home cluster by communicating with the device through the Internet 135, after which the device is managed though direct communication with its home cluster.
• FIG. 1 represents this direct communication with respective arrows 185, 190, 195.
• the service provider provides home networking services and has decided that manager cluster 1 110 should manage all of its home gateway devices and VoIP devices and further that the manager cluster 2 115 should manage all of the television set-top boxes. Accordingly, the arrows 185, 190 represent post-activation traffic directed to manager cluster 1 110, and the arrow 195 represents post- activation traffic directed to manager cluster 2 115.
• FIG. 2 is a block diagram of one embodiment of a scalable distributed multicluster architecture 200 that provides for disaster recovery.
• a "disaster" is defined as an event that causes an extended outage of an affected cluster such that another cluster should perform the functions of the affected cluster at least until the affected cluster is returned to service.
• Manager cluster 2 backup 115-2 includes a bootstrap server (not shown) , a plurality of management servers 117-2 and a data store 118-2.
• Manager cluster 1 backup 110-2 includes a bootstrap server (not shown) , a plurality of management servers 112-2 and a data store 113-2.
• the number of management servers 112-2 in manager cluster 1 backup 110-2 is the same as the number of number of management servers 112 in manager cluster 1 110.
• the number of management servers 117-2 in manager cluster 2 backup 115-2 is the same as the number of number of management servers 117 in manager cluster 2 115.
• the number of management servers in the backups 110-2, 115-2 differs from the number of servers in manager cluster 1 110 and manager cluster 2 115.
• the backups 110-2, 115-2 are only expected to operate under emergent circumstances, and therefore the number of management servers in the backups 110-2, 115-2 is less.
• the data store 113-2 is synchronized with the data store 113, and the data store 118-2 is continually and automatically synchronized with the data store 118.
• a load balancer perhaps executing in the dispatcher cluster 105, redirects devices that are communicating with manager cluster 2 115 to manager cluster 2 backup 115-2 and devices that are communicating with manager cluster 1 110 to manager cluster 2 backup 110 without manual intervention by either the service provider or the subscriber.
• FIG. 2 represents this redirection of direct communication by the devices 140, 145, 150 away from manager cluster 1 110 and manager cluster 2 115 instead to manager cluster 1 backup 110-2 and manager cluster 2 backup 115-2 with respective arrows 185-2, 190-2, 195-2.
• FIG. 3 is a block diagram of one embodiment of a scalable distributed multicluster architecture 300 that provides for dynamic load balancing.
• the architecture of FIG. 3 can be used when a load imbalance occurs between or among home clusters.
• the service provider has the flexibility to provide business rules that allow one or more other ("secondary") clusters temporarily to manage devices they would not manage under ordinary circumstances to balance the load.
• secondary business rules that allow one or more other clusters temporarily to manage devices they would not manage under ordinary circumstances to balance the load.
• IGDs and VoIP devices e.g., the IGD 140 and the VoIP device 1405
• management of those devices may be temporarily or permanently redirected to, e.g., manager cluster 2 115 or another (secondary) cluster (e.g., manager cluster N 120) .
• Arrows 175-3 and 175-4 represent a temporary or permanent redirecting of management responsibility away from manager cluster 1 110 and instead to manager cluster 2 115 or manager cluster N 120.
• one of the functions of the dispatcher cluster 105 is to detect an unbalanced load between or among the manager clusters 110, 115, 120 and cause management of at least some devices to be temporarily redirected according to business rules.
• the data store 108 of the dispatcher cluster 105 stores home and secondary cluster information for devices, so were a home cluster to reject additional devices due to an excessive load, or is completely unavailable, the dispatcher cluster 105 can route devices to its predesignated secondary cluster (s) .
• FIG. 4 is a flow diagram of one embodiment of a method of managing devices using a scalable distributed multicluster architecture.
• the method begins in a start step 410.
• a device initially contacts a dispatcher cluster.
• the dispatcher cluster assigns the device to a manager cluster, which then becomes that device's home cluster, and accordingly causes data reaardincf the device to be transferred to the home cluster.
• the device thereafter directly communicates with, and is managed by, its home cluster.
• the home cluster experiences a disaster. Accordingly, the management of the device is redirected to a manager cluster backup in a step 460.
• a decisional step 470 the home cluster temporarily experiences an excessive load. Accordingly, management of the device is temporarily or permanently redirected to another (secondary) manager cluster in a step 480.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Hardware Redundancy (AREA)
• Computer And Data Communications (AREA)

Priority Applications (5)

Applications Claiming Priority (2)

Publications (1)

Family

ID=47148919

Family Applications (1)

Country Status (7)

Cited By (1)

Families Citing this family (5)

Citations (4)

Family Cites Families (5)

• 2011
  • 2011-10-17 US US13/274,955 patent/US20130097322A1/en not_active Abandoned
• 2012
  • 2012-10-12 WO PCT/US2012/059856 patent/WO2013059076A1/en not_active Ceased
  • 2012-10-12 JP JP2014537127A patent/JP2014532251A/ja active Pending
  • 2012-10-12 EP EP12784123.7A patent/EP2769506A1/en not_active Withdrawn
  • 2012-10-12 IN IN2292CHN2014 patent/IN2014CN02292A/en unknown
  • 2012-10-12 CN CN201280050847.XA patent/CN103931138A/zh active Pending
  • 2012-10-12 KR KR1020147009835A patent/KR20140061534A/ko not_active Ceased

Patent Citations (4)

Also Published As

Similar Documents

Legal Events