US20180011699A1 - Mechanisms for performing switch upgrades using remote containers - Google Patents
Mechanisms for performing switch upgrades using remote containers Download PDFInfo
- Publication number
- US20180011699A1 US20180011699A1 US15/203,583 US201615203583A US2018011699A1 US 20180011699 A1 US20180011699 A1 US 20180011699A1 US 201615203583 A US201615203583 A US 201615203583A US 2018011699 A1 US2018011699 A1 US 2018011699A1
- Authority
- US
- United States
- Prior art keywords
- software container
- container
- software
- network device
- remote server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/128—Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion
-
- G06F17/30088—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
-
- H04L61/1511—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- 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/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/604—Address structures or formats
-
- H04L61/6004—
Definitions
- the present technology pertains to upgrading network switches, and more specifically to upgrading network switches using remote containers.
- ISSU in-service software upgrade
- An ISSU is a solution for updating software on a network device without taking the network device offline and thereby disrupting network services and connectivity.
- ISSU requires a network device with redundant supervisor engines. On modular switches, this allows one engine to operate while the system software on the other engine is updated or upgraded.
- non-modular switches for example Top-of-the-Rack
- similar ISSU can be done with spawning a new container on local switch and following similar approach as modular switches.
- these solutions limit the amount of disruption or downtime experienced when updating or upgrading a network device, they also increase the minimum memory requirements on the platform. The increased memory requirements may result in increased costs and operational requirements.
- legacy platforms already deployed may not have adequate memory capabilities to support even the minimum memory requirements to spawn another container for ISSU.
- FIG. 1A illustrates a schematic diagram of an example system for performing switch upgrades
- FIG. 1B illustrates a schematic diagram of data communications during a switch upgrade process
- FIG. 2 illustrates an example method for performing a switch update
- FIG. 3 illustrates an example network device
- FIGS. 4A and 4B illustrate example system embodiments.
- the approaches set forth herein can be used to reduce the memory footprint requirement for supporting network device upgrades with limited or zero downtime or disruptions.
- the approaches set forth herein can be used to reduce the memory requirements for performing in-service software upgrades (ISSU), including single supervisor hitless ISSU.
- ISSU in-service software upgrades
- the approaches set forth herein can be used for upgrading network devices in container-based designs.
- the system software of the network device can be re-designed to run inside a container on the device.
- An upgraded version of container can then be momentarily generated at a server configured to host the container during the upgrade process.
- a lightweight container can be maintained at the device to manage control plane traffic during the upgrade.
- the upgraded container can then replace the old container at the device, so the device does not have to maintain both containers simultaneously.
- a system can be configured to run the system software inside of a first software container at the system.
- the system can verify reachability to a remote server identified for hosting the first software container during an update event, such as a system upgrade.
- the system can then export a state of software processes associated with the first software container to the remote server.
- the state can be exported to the remote server for import into a second software container at the remote server.
- the second software container can be generated based on the state and the first software container.
- the second software container can be an updated/upgraded version of the first software container generated based on the first software container, the state, and one or more updated software applications or images.
- the system can generate a third software container configured to forward traffic (e.g., control traffic) associated with the first software container to the second software container.
- the third software container can be a lightweight container.
- the lightweight container can have a lower memory footprint than the first software container.
- the system can then perform a first switchover operation between the first software container and the third software container.
- the first switchover operation can enable the third software container to forward, to the second container on the remote server, traffic (e.g., control traffic) associated with the first software container.
- the system can also generate a fourth software container based on a snapshot of the second software container on the remote server.
- the fourth software container can include the state of the second software container as well as the software applications and drivers from the second software container, for example.
- the fourth software container can include all the updates or upgrades selected or identified for updating/upgrading the first software container.
- the system can generate the fourth software container on the local system (e.g., hosted on local memory or drive associated with the system).
- the system can generate the fourth software container on a separate system or device and subsequently move the fourth software container to the system to run on the system.
- the system can perform a second switchover operation between the third software container and the fourth software container.
- the second switchover operation can include enabling the fourth software container to handle traffic associated with the first software container, and/or disabling the third software container on the network device and second software container on the server.
- the system can then use the fourth software container as the active container on the system.
- the fourth software container can include the system software for operating the system.
- the disclosure addresses the need in the art for reducing the memory footprint of switch upgrade procedures.
- FIG. 1A illustrates a schematic diagram of an example system 100 for performing switch upgrades.
- Switch 102 can be configured to run the system software 106 , such as the operating system (OS), drivers, and applications, in a container 104 .
- the container 104 can include or host one or more services, applications, drivers, libraries, environments, etc.
- the container 104 can be a virtualized environment for deploying services and/or applications at the switch 102 .
- switch 102 can include a container virtualization layer for hosting or deploying one or more services, applications, and/or software drivers. This container virtualization layer, including software 106 , can make up the container 104 .
- Server 108 can be a separate device which can be used to assist in the upgrade by hosting a copy of the container 104 during the upgrade process.
- server 108 can host container 110 during the upgrade process.
- Container 110 can be a copy of container 104 .
- container 110 can include the upgraded software 112 , which can include the upgraded system image, operating system, applications, libraries, and/or drivers.
- the software 112 can be based on the new target or upgrade image, which can include any new software or elements to which we are upgrading.
- Container 110 and/or software 112 can be upgraded as they are generated on server 108 or after being generated on server 108 .
- container 110 and software 112 can be generated based on the updated version of the software to be upgraded, or generated based on container 104 and software 106 and thereafter upgraded based on the updated version of the software to be upgraded.
- Container 110 and software 112 can also include any other modifications to container 104 and 106 , such as new or modified settings, new or modified applications or software, new or modified files, etc.
- Switch 102 can export the state information associated with the applications and/or processes in container 104 to server 108 .
- Server 108 can receive the state information and import it into container 110 .
- container 110 and software 112 can be deployed with the state information to reflect the current state on switch 102 .
- the network name and/or domain naming system (DNS) of the server 108 can be configured on the switch 102 to ensure network connectivity to and from the container 110 .
- switch 102 can probe the server 108 to verify reachability.
- Server 108 can have a configurable network address (e.g., IP address).
- Switch 102 can also define the network address for switch 102 and/or container 110 . For example, switch 102 can test all of its own network addresses to identify which network address receives a successful probe response. The network address that receives the successful probe response can be set as the network address for the probes, switch 102 , and/or container 110 .
- a lightweight container 114 can be generated at the switch 102 .
- the lightweight container 114 can perform hardware read and write operations at switch 102 , and can include the user space drivers of switch 102 to manage the hardware of switch 102 .
- the lightweight container 114 can also include a module to perform encapsulation and decapsulation of control plane traffic from switch 102 to server 108 . This way, the lightweight container 114 can continue to handle traffic (e.g., control traffic) directed to container 104 during the upgrade process, by tunneling the traffic from switch 102 to server 108 to be processed by container 110 .
- traffic e.g., control traffic
- the lightweight container 114 does not need to have all of the OS applications running and, therefore, should have minimal memory requirements compared to container 104 .
- the reduced memory requirements of the lightweight container 114 can allow the upgrade process to be performed using significantly less memory on the switch 102 than would normally be required when performing an in-service software upgrade (ISSU).
- ISSU in-service software upgrade
- the switch 102 can perform a switchover operation.
- the switchover operation changes control from container 104 to the lightweight container 114 .
- the switchover operation can thus activate or enable the lightweight container 114 , which can begin to tunnel control plane traffic from switch 102 to container 110 on server 108 .
- the switch 102 can then destroy, delete, and/or remove the container 104 .
- the switch 102 can also generate container 116 with software 118 on switch 102 .
- the container 116 can be generated based on a snapshot of container 110 and software 112 on server 108 .
- the snapshot can include the state information at container 110 .
- the container 116 and software 118 includes any updates, upgrades, and/or modifications made to container 104 and software 102 .
- the switch 102 can perform another switchover operation to enable or activate container 116 and disable or deactivate lightweight container 114 .
- container 116 can continue to handle and process traffic to the switch 102 .
- the traffic is no longer tunneled to, or processed by, container 110 .
- the container 110 can be removed from server 108 and/or destroyed.
- the lightweight container 114 can also be destroyed, deleted, and/or removed from the switch 102 .
- the switch 102 can perform a line card container upgrade to update any line card settings for the upgraded container 116 and software 118 .
- FIG. 1B illustrates a schematic diagram 150 of data communications during a switch upgrade process.
- container 104 can handle incoming communications ( 1 ) directed at container 104 , as well as outgoing communications ( 2 ).
- the incoming communications can include packets, such as control packets.
- the lightweight container 114 can receive incoming communications ( 1 ) and tunnel the communications ( 2 ) to container 110 , which can then process the communications, and return the communications ( 3 ) to the lightweight container 114 .
- the lightweight container 114 can receive the communications ( 3 ) from the container 110 and transmit the communications ( 4 ) as necessary.
- the lightweight container 114 can continue to receive the incoming communications ( 1 ) and tunnel the communications ( 2 ) to container 110 , which can process the communications, and return the communications ( 3 ) to the lightweight container 114 .
- the lightweight container 114 can receive the communications ( 3 ) from the container 110 and transmit the communications ( 4 ) as necessary.
- the lightweight container 114 can continue to receive incoming communications ( 1 ), transmit the communications ( 2 ) to the container 110 on the server, receive the processed communications ( 3 ) from the container 110 , and transmit the communications ( 4 ) out as necessary.
- the container 116 can start receiving incoming communications ( 1 ) and processing the communications ( 2 ).
- the lightweight container 114 on the switch 102 and container 110 on the server 108 can be destroyed, removed, and/or disabled.
- switch 102 and server 108 can work together at stages A-E to continue to handle communications associated with container 104 during the upgrade process. This can reduce or eliminate the disruption or downtime experienced by switch 102 during the upgrade process.
- FIG. 2 For the sake of clarity, the method is described in terms of a switch 102 and server 108 , as shown in FIGS. 1A-B , configured to practice the various steps of the method.
- the steps outlined herein are exemplary and can be implemented in any combination thereof, including combinations that exclude, add, or modify certain steps.
- the switch 102 can be configured to run the system software inside of a software container 104 at the switch 102 .
- the system software can include the OS, device drivers, applications, etc.
- a server 108 can be identified for hosting the software container 104 during an update event.
- the update event can be an update or upgrade of the content in the container 104 (e.g., system software, applications, etc.), a modification of the content in the container 104 (e.g., adding, modifying, removing software, etc.), a re-install of software and applications, etc.
- the switch 102 can send probes to verify reachability prior to performing the update process.
- the switch 102 can ping or probe various network addresses (e.g., IPs) to determine reachability of the server 108 , including any network addresses at the switch 102 .
- the DNS information and/or network name of server 108 can also be configured on the switch 102 to enable communications during the update process.
- the switch 102 can thus establish a communication channel with the server 108 for use during the update process.
- the switch 102 can export to the server 108 the state of software processes associated with the software container 104 .
- the state can be exported for import into software container 110 at server 108 .
- software container 110 can be deployed on server 108 as part of the update process.
- software container 110 can be generated on server 108 based on the software container 104 .
- software container 110 can be a copy or export of software container 104 .
- software container 110 can be an updated/upgraded version of software container 104 .
- software container 110 can be generated based on software container 104 , but using an upgraded or updated image of the software 106 associated with software container 104 .
- the state exported from container 104 can be imported or incorporated into software container 110 . Accordingly, when software container 110 is launched or deployed, it can start with the current state of the software, processes, and applications of software container 104 .
- the switch 102 can deploy a lightweight software container 114 configured to forward traffic associated with the software container 104 to the software container 110 at server 108 .
- the lightweight container 114 can include software and drivers to allow hardware read and write and manage the hardware of the switch 102 .
- the lightweight container 114 can include one or more modules configured to perform encapsulation and decapsulation of control plane traffic from the switch 102 to the container 110 at the server 108 .
- the lightweight container 114 does not have to run or include all of the software applications from software container 104 , and thus can have a lower memory footprint than the software container 104 . In some cases, the lightweight container 114 can require significantly less memory than the software container 104 being upgraded/updated.
- the switch 102 can perform a switchover operation between the software container 104 and the lightweight software container 114 .
- the switchover operation can enable the lightweight software container 114 to forward traffic associated with the software container 104 to the software container 110 at server 108 .
- traffic directed to container 104 can be tunneled by the lightweight software container 114 to the software container 110 at server 108 .
- the software container 114 can then process the traffic intended for container 104 as would otherwise have been processed by container 104 , in order to reduce or eliminate any disruptions of service during the update process.
- the switch 102 can remove the software container 104 . This can free up memory or space on the switch 102 for storing the new, upgraded software container.
- the switch 102 can deploy software container 116 based on a snapshot of the software container 110 on the server 108 .
- the software container 116 can be a copy of the software container 110 at server 108 .
- the software container 116 can include the state of software container 110 , as well as software 112 .
- the software container 116 can include any updates, upgrades, and/or modifications made to software container 104 as part of the update process.
- the switch 102 can perform a switchover operation between the lightweight software container 114 and the software container 116 .
- the switchover operation include enabling the software container 116 to handle traffic associated with the software container 104 and/or disabling the lightweight software container 114 on the switch 102 .
- software container 116 when software container 116 is ready to become operational, it can be set to take over any operations performed by the lightweight container 114 and the software container 110 during the update process.
- the method can include removing (e.g., destroying, disabling, deleting, etc.) the software container 110 on the server 108 and the lightweight container 114 on the switch 102 .
- the switch 102 can perform other tweaks or updates, such as line card updates, to finalize the installation.
- the software container 116 can then fully replace the software container 104 as the updated, upgraded, or modified version of the software container 104 .
- the update process of method 200 can also be performed for migrating and/or replacing software and containers.
- the method 200 is described herein with reference to a switch, other devices are contemplated herein, such as routers, bridges, servers, single supervisor engine devices, dual supervisor engine devices, etc.
- FIGS. 3 and 4 illustrate example network and system devices.
- FIG. 3 illustrates an example network device 300 suitable for high availability and failover.
- Network device 300 can include a master central processing unit (CPU) 304 , interfaces 302 , and a bus 310 (e.g., a PCI bus).
- CPU central processing unit
- the CPU 304 can be responsible for executing packet management, error detection, and/or routing functions.
- the CPU 304 can accomplish all these functions under the control of software including an operating system and any appropriate applications software.
- CPU 304 may include one or more processors 308 , such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors.
- processor 308 is specially designed hardware for controlling the operations of the network device 300 .
- a memory 306 (such as non-volatile RAM, ROM, TCAM, etc.) can also form part of CPU 304 . However, there are many different ways in which memory could be coupled to the network device 300 .
- the interfaces 302 can be provided as interface cards (sometimes referred to as “line cards”).
- the interfaces 302 can control the sending and receiving of packets over the network, and support other peripherals used with the network device 300 .
- the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, Layer 1 interfaces, fiber optic interfaces, and so forth.
- various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces (e.g., 10, 25, 40, 50, 100 GbE, etc.), ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like.
- these interfaces may include ports appropriate for communication with the appropriate media.
- the master microprocessor 304 may also include an independent processor and, in some instances, volatile RAM.
- the independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 304 to efficiently perform routing computations, network diagnostics, security functions, etc.
- the network device 300 can also include an application specific integrated circuit or ASIC 312 .
- the ASIC 312 can communicate with other components in the network device 300 (e.g., interfaces 302 , CPU 304 , memory 306 , processor 308 , etc.) via the bus 310 .
- the ASIC 312 can be an integrated circuit customized for a particular use, such as routing operations, including forwarding operations.
- FIG. 3 is one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented.
- an architecture having a single processor that handles communications as well as routing computations, etc. is often used.
- other types of interfaces and media could also be used with the router.
- the network device may employ one or more memories or memory modules (including memory 306 ) configured to store program instructions for the general-purpose network operations and mechanisms for roaming, route optimization and routing functions described herein.
- the program instructions may control the operation of an operating system and/or one or more applications, for example.
- the memory or memories may also be configured to store tables such as mobility binding, registration, and association tables, etc.
- FIG. 4A and FIG. 4B illustrate example system embodiments. The more appropriate embodiment will be apparent to those of ordinary skill in the art when practicing the present technology. Persons of ordinary skill in the art will also readily appreciate that other system embodiments are possible.
- FIG. 4A illustrates a conventional system bus computing system architecture 400 wherein the components of the system are in electrical communication with each other using a bus 406 .
- Exemplary system 400 includes a processing unit (CPU or processor) 404 and a system bus 406 that couples various system components including the system memory 420 , such as read only memory (ROM) 418 and random access memory (RAM) 416 , to the processor 404 .
- the system 400 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor 404 .
- the system 400 can copy data from the memory 420 and/or the storage device 408 to the cache 402 for quick access by the processor 404 .
- the cache can provide a performance boost that avoids processor 404 delays while waiting for data.
- These and other modules can control or be configured to control the processor 404 to perform various actions.
- Other system memory 420 may be available for use as well.
- the memory 420 can include multiple different types of memory with different performance characteristics.
- the processor 404 can include any general purpose processor and a hardware module or software module, such as module 1 410 , module 2 412 , and module 3 414 stored in storage device 408 , configured to control the processor 404 as well as a special-purpose processor where software instructions are incorporated into the actual processor design.
- the processor 404 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc.
- a multi-core processor may be symmetric or asymmetric.
- an input device 422 can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth.
- An output device 424 can also be one or more of a number of output mechanisms known to those of skill in the art.
- multimodal systems can enable a user to provide multiple types of input to communicate with the computing device 400 .
- the communications interface 426 can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.
- Storage device 408 is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 416 , read only memory (ROM) 418 , and hybrids thereof.
- RAMs random access memories
- ROM read only memory
- the storage device 408 can include software modules 410 , 412 , 414 for controlling the processor 404 . Other hardware or software modules are contemplated.
- the storage device 408 can be connected to the system bus 406 .
- a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor 404 , bus 406 , output device (e.g., display) 424 , and so forth, to carry out the function.
- the system 400 can also include an application specific integrated circuit or ASIC 428 .
- the ASIC 428 can communicate with other components in the system 400 (e.g., components 402 - 426 ) via the bus 406 .
- the ASIC 428 can be an integrated circuit customized for a particular use, such as routing operations, including forwarding operations.
- FIG. 4B illustrates an example computer system 450 having a chipset architecture that can be used in executing the described method and generating and displaying a graphical user interface (GUI).
- Computer system 450 is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology.
- System 450 can include a processor 452 , representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations.
- Processor 452 can communicate with a chipset 454 that can control input to and output from processor 452 .
- chipset 454 outputs information to output device 462 , such as a display, and can read and write information to storage device 464 , which can include magnetic media, and solid state media, for example.
- Chipset 454 can also read data from and write data to RAM 466 .
- a bridge 456 for interfacing with a variety of user interface components 458 can be provided for interfacing with chipset 454 .
- Such user interface components 458 can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on.
- inputs to system 450 can come from any of a variety of sources, machine generated and/or human generated.
- Chipset 454 can also interface with one or more communication interfaces 490 that can have different physical interfaces.
- Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks.
- Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself by processor 452 analyzing data stored in storage 464 or 466 . Further, the machine can receive inputs from a user via user interface components 458 and execute appropriate functions, such as browsing functions by interpreting these inputs using processor 452 .
- example systems 400 and 450 can have more than one processor or be part of a group or cluster of computing devices networked together to provide greater processing capability.
- the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.
- the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like.
- Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network.
- the computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.
- Devices implementing methods according to these disclosures can include hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.
- the instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.
- claim language reciting “at least one of” a set indicates that one member of the set or multiple members of the set satisfy the claim.
- claim language reciting “at least one of A and B” can include A only, B only, or A and B.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Stored Programmes (AREA)
Abstract
Description
- The present technology pertains to upgrading network switches, and more specifically to upgrading network switches using remote containers.
- Various solutions have been developed to limit the amount of downtime experienced when updating or upgrading network devices in a network. For example, An ISSU (in-service software upgrade) is a solution for updating software on a network device without taking the network device offline and thereby disrupting network services and connectivity. Generally, ISSU requires a network device with redundant supervisor engines. On modular switches, this allows one engine to operate while the system software on the other engine is updated or upgraded. On non-modular switches (for example Top-of-the-Rack), similar ISSU can be done with spawning a new container on local switch and following similar approach as modular switches. While these solutions limit the amount of disruption or downtime experienced when updating or upgrading a network device, they also increase the minimum memory requirements on the platform. The increased memory requirements may result in increased costs and operational requirements. Moreover, in some cases, legacy platforms already deployed may not have adequate memory capabilities to support even the minimum memory requirements to spawn another container for ISSU.
- In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:
-
FIG. 1A illustrates a schematic diagram of an example system for performing switch upgrades; -
FIG. 1B illustrates a schematic diagram of data communications during a switch upgrade process; -
FIG. 2 illustrates an example method for performing a switch update; -
FIG. 3 illustrates an example network device; and -
FIGS. 4A and 4B illustrate example system embodiments. - Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure.
- Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.
- The approaches set forth herein can be used to reduce the memory footprint requirement for supporting network device upgrades with limited or zero downtime or disruptions. For example, the approaches set forth herein can be used to reduce the memory requirements for performing in-service software upgrades (ISSU), including single supervisor hitless ISSU. Moreover, the approaches set forth herein can be used for upgrading network devices in container-based designs.
- For example, to upgrade a network device, the system software of the network device can be re-designed to run inside a container on the device. An upgraded version of container can then be momentarily generated at a server configured to host the container during the upgrade process. A lightweight container can be maintained at the device to manage control plane traffic during the upgrade. The upgraded container can then replace the old container at the device, so the device does not have to maintain both containers simultaneously. By eliminating the need to host multiple full-blown containers at a time, the approaches herein can significantly reduce the memory requirements for ISSU and similar upgrades.
- Disclosed are systems, methods, and computer-readable storage media for performing single supervisor switch upgrades using remote containers. In some examples, a system can be configured to run the system software inside of a first software container at the system. The system can verify reachability to a remote server identified for hosting the first software container during an update event, such as a system upgrade. The system can then export a state of software processes associated with the first software container to the remote server. The state can be exported to the remote server for import into a second software container at the remote server. The second software container can be generated based on the state and the first software container. For example, the second software container can be an updated/upgraded version of the first software container generated based on the first software container, the state, and one or more updated software applications or images.
- The system can generate a third software container configured to forward traffic (e.g., control traffic) associated with the first software container to the second software container. The third software container can be a lightweight container. The lightweight container can have a lower memory footprint than the first software container. The system can then perform a first switchover operation between the first software container and the third software container. The first switchover operation can enable the third software container to forward, to the second container on the remote server, traffic (e.g., control traffic) associated with the first software container.
- The system can also generate a fourth software container based on a snapshot of the second software container on the remote server. The fourth software container can include the state of the second software container as well as the software applications and drivers from the second software container, for example. The fourth software container can include all the updates or upgrades selected or identified for updating/upgrading the first software container.
- The system can generate the fourth software container on the local system (e.g., hosted on local memory or drive associated with the system). In some examples, the system can generate the fourth software container on a separate system or device and subsequently move the fourth software container to the system to run on the system.
- Once the fourth software container is on the system, the system can perform a second switchover operation between the third software container and the fourth software container. The second switchover operation can include enabling the fourth software container to handle traffic associated with the first software container, and/or disabling the third software container on the network device and second software container on the server. The system can then use the fourth software container as the active container on the system. The fourth software container can include the system software for operating the system.
- The disclosure addresses the need in the art for reducing the memory footprint of switch upgrade procedures. Disclosed are systems, method, and computer-readable media for performing single supervisor switch upgrades using remote containers. As follows, the disclosure starts with a discussion of example architectures and configurations for switch upgrade procedures. Example methods and strategies for performing switch upgrades with then follow. The disclosure then concludes with a description of example systems and devices for performing switch upgrades. The disclosure now turns to
FIG. 1 . -
FIG. 1A illustrates a schematic diagram of anexample system 100 for performing switch upgrades. Switch 102 can be configured to run thesystem software 106, such as the operating system (OS), drivers, and applications, in acontainer 104. Thecontainer 104 can include or host one or more services, applications, drivers, libraries, environments, etc. As one of ordinary skill in the art will recognize, thecontainer 104 can be a virtualized environment for deploying services and/or applications at theswitch 102. For example, switch 102 can include a container virtualization layer for hosting or deploying one or more services, applications, and/or software drivers. This container virtualization layer, includingsoftware 106, can make up thecontainer 104. -
Server 108 can be a separate device which can be used to assist in the upgrade by hosting a copy of thecontainer 104 during the upgrade process. In particular,server 108 can hostcontainer 110 during the upgrade process.Container 110 can be a copy ofcontainer 104. Moreover,container 110 can include the upgradedsoftware 112, which can include the upgraded system image, operating system, applications, libraries, and/or drivers. Thesoftware 112 can be based on the new target or upgrade image, which can include any new software or elements to which we are upgrading. -
Container 110 and/orsoftware 112 can be upgraded as they are generated onserver 108 or after being generated onserver 108. For example,container 110 andsoftware 112 can be generated based on the updated version of the software to be upgraded, or generated based oncontainer 104 andsoftware 106 and thereafter upgraded based on the updated version of the software to be upgraded.Container 110 andsoftware 112 can also include any other modifications tocontainer - Switch 102 can export the state information associated with the applications and/or processes in
container 104 toserver 108.Server 108 can receive the state information and import it intocontainer 110. Accordingly,container 110 andsoftware 112 can be deployed with the state information to reflect the current state onswitch 102. - The network name and/or domain naming system (DNS) of the
server 108 can be configured on theswitch 102 to ensure network connectivity to and from thecontainer 110. Moreover, prior to exporting the state information, switch 102 can probe theserver 108 to verify reachability.Server 108 can have a configurable network address (e.g., IP address). Switch 102 can also define the network address forswitch 102 and/orcontainer 110. For example, switch 102 can test all of its own network addresses to identify which network address receives a successful probe response. The network address that receives the successful probe response can be set as the network address for the probes,switch 102, and/orcontainer 110. - Once the
container 110 has been generated on theserver 108, alightweight container 114 can be generated at theswitch 102. Thelightweight container 114 can perform hardware read and write operations atswitch 102, and can include the user space drivers ofswitch 102 to manage the hardware ofswitch 102. Thelightweight container 114 can also include a module to perform encapsulation and decapsulation of control plane traffic fromswitch 102 toserver 108. This way, thelightweight container 114 can continue to handle traffic (e.g., control traffic) directed tocontainer 104 during the upgrade process, by tunneling the traffic fromswitch 102 toserver 108 to be processed bycontainer 110. - The
lightweight container 114 does not need to have all of the OS applications running and, therefore, should have minimal memory requirements compared tocontainer 104. The reduced memory requirements of thelightweight container 114 can allow the upgrade process to be performed using significantly less memory on theswitch 102 than would normally be required when performing an in-service software upgrade (ISSU). - Once the
lightweight container 114 has been generated, theswitch 102 can perform a switchover operation. The switchover operation changes control fromcontainer 104 to thelightweight container 114. The switchover operation can thus activate or enable thelightweight container 114, which can begin to tunnel control plane traffic fromswitch 102 tocontainer 110 onserver 108. - The
switch 102 can then destroy, delete, and/or remove thecontainer 104. Theswitch 102 can also generatecontainer 116 withsoftware 118 onswitch 102. Thecontainer 116 can be generated based on a snapshot ofcontainer 110 andsoftware 112 onserver 108. The snapshot can include the state information atcontainer 110. Thecontainer 116 andsoftware 118 includes any updates, upgrades, and/or modifications made tocontainer 104 andsoftware 102. - Once the
container 116 is operational, theswitch 102 can perform another switchover operation to enable or activatecontainer 116 and disable or deactivatelightweight container 114. After the switchover operation,container 116 can continue to handle and process traffic to theswitch 102. Moreover, the traffic is no longer tunneled to, or processed by,container 110. Thus, thecontainer 110 can be removed fromserver 108 and/or destroyed. Thelightweight container 114 can also be destroyed, deleted, and/or removed from theswitch 102. - The
switch 102 can perform a line card container upgrade to update any line card settings for the upgradedcontainer 116 andsoftware 118. -
FIG. 1B illustrates a schematic diagram 150 of data communications during a switch upgrade process. At stage A,container 104 can handle incoming communications (1) directed atcontainer 104, as well as outgoing communications (2). The incoming communications can include packets, such as control packets. - At stage B, once the
container 110 has been generated atserver 108 andlightweight container 114 is operational atswitch 102, thelightweight container 114 can receive incoming communications (1) and tunnel the communications (2) tocontainer 110, which can then process the communications, and return the communications (3) to thelightweight container 114. Thelightweight container 114 can receive the communications (3) from thecontainer 110 and transmit the communications (4) as necessary. - At stage C, throughout the destruction of
container 104 onswitch 102, thelightweight container 114 can continue to receive the incoming communications (1) and tunnel the communications (2) tocontainer 110, which can process the communications, and return the communications (3) to thelightweight container 114. Thelightweight container 114 can receive the communications (3) from thecontainer 110 and transmit the communications (4) as necessary. - At stage D, while the
container 116 is spawned atswitch 102, thelightweight container 114 can continue to receive incoming communications (1), transmit the communications (2) to thecontainer 110 on the server, receive the processed communications (3) from thecontainer 110, and transmit the communications (4) out as necessary. - At stage E, once the
container 116 is enabled or activated on theswitch 102, thecontainer 116 can start receiving incoming communications (1) and processing the communications (2). Thelightweight container 114 on theswitch 102 andcontainer 110 on theserver 108 can be destroyed, removed, and/or disabled. - As illustrated,
switch 102 andserver 108 can work together at stages A-E to continue to handle communications associated withcontainer 104 during the upgrade process. This can reduce or eliminate the disruption or downtime experienced byswitch 102 during the upgrade process. - Having disclosed some basic system components and concepts, the disclosure now turns to the exemplary method embodiment shown in
FIG. 2 . For the sake of clarity, the method is described in terms of aswitch 102 andserver 108, as shown inFIGS. 1A-B , configured to practice the various steps of the method. The steps outlined herein are exemplary and can be implemented in any combination thereof, including combinations that exclude, add, or modify certain steps. - At
step 200, theswitch 102 can be configured to run the system software inside of asoftware container 104 at theswitch 102. The system software can include the OS, device drivers, applications, etc. Atstep 202, aserver 108 can be identified for hosting thesoftware container 104 during an update event. The update event can be an update or upgrade of the content in the container 104 (e.g., system software, applications, etc.), a modification of the content in the container 104 (e.g., adding, modifying, removing software, etc.), a re-install of software and applications, etc. - Once the
server 108 has been identified, theswitch 102 can send probes to verify reachability prior to performing the update process. Theswitch 102 can ping or probe various network addresses (e.g., IPs) to determine reachability of theserver 108, including any network addresses at theswitch 102. The DNS information and/or network name ofserver 108 can also be configured on theswitch 102 to enable communications during the update process. Theswitch 102 can thus establish a communication channel with theserver 108 for use during the update process. - At
step 204, theswitch 102 can export to theserver 108 the state of software processes associated with thesoftware container 104. The state can be exported for import intosoftware container 110 atserver 108. As previously mentioned,software container 110 can be deployed onserver 108 as part of the update process. In particular,software container 110 can be generated onserver 108 based on thesoftware container 104. For example,software container 110 can be a copy or export ofsoftware container 104. In some example,software container 110 can be an updated/upgraded version ofsoftware container 104. For example,software container 110 can be generated based onsoftware container 104, but using an upgraded or updated image of thesoftware 106 associated withsoftware container 104. In addition, the state exported fromcontainer 104 can be imported or incorporated intosoftware container 110. Accordingly, whensoftware container 110 is launched or deployed, it can start with the current state of the software, processes, and applications ofsoftware container 104. - At
step 206, theswitch 102 can deploy alightweight software container 114 configured to forward traffic associated with thesoftware container 104 to thesoftware container 110 atserver 108. Thelightweight container 114 can include software and drivers to allow hardware read and write and manage the hardware of theswitch 102. Moreover, thelightweight container 114 can include one or more modules configured to perform encapsulation and decapsulation of control plane traffic from theswitch 102 to thecontainer 110 at theserver 108. Thelightweight container 114 does not have to run or include all of the software applications fromsoftware container 104, and thus can have a lower memory footprint than thesoftware container 104. In some cases, thelightweight container 114 can require significantly less memory than thesoftware container 104 being upgraded/updated. - At
step 208, theswitch 102 can perform a switchover operation between thesoftware container 104 and thelightweight software container 114. The switchover operation can enable thelightweight software container 114 to forward traffic associated with thesoftware container 104 to thesoftware container 110 atserver 108. Thus, during the update process, traffic directed tocontainer 104 can be tunneled by thelightweight software container 114 to thesoftware container 110 atserver 108. Thesoftware container 114 can then process the traffic intended forcontainer 104 as would otherwise have been processed bycontainer 104, in order to reduce or eliminate any disruptions of service during the update process. - At
step 210, theswitch 102 can remove thesoftware container 104. This can free up memory or space on theswitch 102 for storing the new, upgraded software container. - At
step 212, theswitch 102 can deploysoftware container 116 based on a snapshot of thesoftware container 110 on theserver 108. Thesoftware container 116 can be a copy of thesoftware container 110 atserver 108. Moreover, thesoftware container 116 can include the state ofsoftware container 110, as well assoftware 112. When deployed, thesoftware container 116 can include any updates, upgrades, and/or modifications made tosoftware container 104 as part of the update process. - At
step 214, theswitch 102 can perform a switchover operation between thelightweight software container 114 and thesoftware container 116. The switchover operation include enabling thesoftware container 116 to handle traffic associated with thesoftware container 104 and/or disabling thelightweight software container 114 on theswitch 102. Thus, whensoftware container 116 is ready to become operational, it can be set to take over any operations performed by thelightweight container 114 and thesoftware container 110 during the update process. - At
step 216, the method can include removing (e.g., destroying, disabling, deleting, etc.) thesoftware container 110 on theserver 108 and thelightweight container 114 on theswitch 102. - In some cases, after
steps 214 and/or 216, theswitch 102 can perform other tweaks or updates, such as line card updates, to finalize the installation. Thesoftware container 116 can then fully replace thesoftware container 104 as the updated, upgraded, or modified version of thesoftware container 104. - The update process of
method 200 can also be performed for migrating and/or replacing software and containers. Moreover, while themethod 200 is described herein with reference to a switch, other devices are contemplated herein, such as routers, bridges, servers, single supervisor engine devices, dual supervisor engine devices, etc. - The disclosure now turns to
FIGS. 3 and 4 , which illustrate example network and system devices. -
FIG. 3 illustrates anexample network device 300 suitable for high availability and failover.Network device 300 can include a master central processing unit (CPU) 304,interfaces 302, and a bus 310 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, theCPU 304 can be responsible for executing packet management, error detection, and/or routing functions. TheCPU 304 can accomplish all these functions under the control of software including an operating system and any appropriate applications software.CPU 304 may include one ormore processors 308, such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative configuration,processor 308 is specially designed hardware for controlling the operations of thenetwork device 300. In some cases, a memory 306 (such as non-volatile RAM, ROM, TCAM, etc.) can also form part ofCPU 304. However, there are many different ways in which memory could be coupled to thenetwork device 300. - The
interfaces 302 can be provided as interface cards (sometimes referred to as “line cards”). - Generally, the
interfaces 302 can control the sending and receiving of packets over the network, and support other peripherals used with thenetwork device 300. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces,Layer 1 interfaces, fiber optic interfaces, and so forth. In addition, various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces (e.g., 10, 25, 40, 50, 100 GbE, etc.), ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow themaster microprocessor 304 to efficiently perform routing computations, network diagnostics, security functions, etc. - The
network device 300 can also include an application specific integrated circuit orASIC 312. TheASIC 312 can communicate with other components in the network device 300 (e.g., interfaces 302,CPU 304,memory 306,processor 308, etc.) via thebus 310. TheASIC 312 can be an integrated circuit customized for a particular use, such as routing operations, including forwarding operations. - Although the system shown in
FIG. 3 is one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the router. - Regardless of the network device's configuration, it may employ one or more memories or memory modules (including memory 306) configured to store program instructions for the general-purpose network operations and mechanisms for roaming, route optimization and routing functions described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The memory or memories may also be configured to store tables such as mobility binding, registration, and association tables, etc.
-
FIG. 4A andFIG. 4B illustrate example system embodiments. The more appropriate embodiment will be apparent to those of ordinary skill in the art when practicing the present technology. Persons of ordinary skill in the art will also readily appreciate that other system embodiments are possible. -
FIG. 4A illustrates a conventional system buscomputing system architecture 400 wherein the components of the system are in electrical communication with each other using abus 406.Exemplary system 400 includes a processing unit (CPU or processor) 404 and asystem bus 406 that couples various system components including thesystem memory 420, such as read only memory (ROM) 418 and random access memory (RAM) 416, to theprocessor 404. Thesystem 400 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of theprocessor 404. Thesystem 400 can copy data from thememory 420 and/or thestorage device 408 to thecache 402 for quick access by theprocessor 404. In this way, the cache can provide a performance boost that avoidsprocessor 404 delays while waiting for data. These and other modules can control or be configured to control theprocessor 404 to perform various actions.Other system memory 420 may be available for use as well. Thememory 420 can include multiple different types of memory with different performance characteristics. Theprocessor 404 can include any general purpose processor and a hardware module or software module, such asmodule 1 410,module 2 412, andmodule 3 414 stored instorage device 408, configured to control theprocessor 404 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Theprocessor 404 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric. - To enable user interaction with the
computing device 400, aninput device 422 can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. Anoutput device 424 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with thecomputing device 400. Thecommunications interface 426 can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed. -
Storage device 408 is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 416, read only memory (ROM) 418, and hybrids thereof. - The
storage device 408 can includesoftware modules processor 404. Other hardware or software modules are contemplated. Thestorage device 408 can be connected to thesystem bus 406. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as theprocessor 404,bus 406, output device (e.g., display) 424, and so forth, to carry out the function. - The
system 400 can also include an application specific integrated circuit orASIC 428. TheASIC 428 can communicate with other components in the system 400 (e.g., components 402-426) via thebus 406. TheASIC 428 can be an integrated circuit customized for a particular use, such as routing operations, including forwarding operations. -
FIG. 4B illustrates anexample computer system 450 having a chipset architecture that can be used in executing the described method and generating and displaying a graphical user interface (GUI).Computer system 450 is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology.System 450 can include aprocessor 452, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations.Processor 452 can communicate with achipset 454 that can control input to and output fromprocessor 452. In this example,chipset 454 outputs information tooutput device 462, such as a display, and can read and write information tostorage device 464, which can include magnetic media, and solid state media, for example.Chipset 454 can also read data from and write data to RAM 466. Abridge 456 for interfacing with a variety ofuser interface components 458 can be provided for interfacing withchipset 454. Suchuser interface components 458 can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on. In general, inputs tosystem 450 can come from any of a variety of sources, machine generated and/or human generated. -
Chipset 454 can also interface with one or more communication interfaces 490 that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself byprocessor 452 analyzing data stored instorage user interface components 458 and execute appropriate functions, such as browsing functions by interpreting theseinputs using processor 452. - It can be appreciated that
example systems - For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.
- In some embodiments the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like.
- Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.
- Devices implementing methods according to these disclosures can include hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.
- The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.
- Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.
- Moreover, claim language reciting “at least one of” a set indicates that one member of the set or multiple members of the set satisfy the claim. For example, claim language reciting “at least one of A and B” can include A only, B only, or A and B.
Claims (21)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/203,583 US9870219B1 (en) | 2016-07-06 | 2016-07-06 | Mechanisms for performing switch upgrades using remote containers |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/203,583 US9870219B1 (en) | 2016-07-06 | 2016-07-06 | Mechanisms for performing switch upgrades using remote containers |
Publications (2)
Publication Number | Publication Date |
---|---|
US20180011699A1 true US20180011699A1 (en) | 2018-01-11 |
US9870219B1 US9870219B1 (en) | 2018-01-16 |
Family
ID=60910380
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/203,583 Expired - Fee Related US9870219B1 (en) | 2016-07-06 | 2016-07-06 | Mechanisms for performing switch upgrades using remote containers |
Country Status (1)
Country | Link |
---|---|
US (1) | US9870219B1 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180053001A1 (en) * | 2016-08-16 | 2018-02-22 | International Business Machines Corporation | Security fix of a container in a virtual machine environment |
US20180121189A1 (en) * | 2016-10-28 | 2018-05-03 | Parallels International Gmbh | System and method for upgrading operating system of a container using an auxiliary host |
CN108804129A (en) * | 2018-05-31 | 2018-11-13 | 新华三技术有限公司 | A kind of method for upgrading software and device |
CN108984195A (en) * | 2018-06-27 | 2018-12-11 | 新华三技术有限公司 | A kind of method for upgrading software and device |
CN113660123A (en) * | 2021-08-16 | 2021-11-16 | 杭州朗和科技有限公司 | Virtual switch upgrading method and device, electronic equipment and storage medium |
US20230103223A1 (en) * | 2021-09-24 | 2023-03-30 | Sap Se | Cloud application management using instance metadata |
US11841731B2 (en) | 2021-09-24 | 2023-12-12 | Sap Se | Cloud plugin for legacy on-premise application |
US20240022472A1 (en) * | 2022-07-13 | 2024-01-18 | Dell Products L.P. | Systems and methods for deploying third-party applications on a cluster of network switches |
US11922163B2 (en) | 2021-09-24 | 2024-03-05 | Sap Se | Cloud version management for legacy on-premise application |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10838711B2 (en) | 2018-09-20 | 2020-11-17 | Mellanox Technologies Tlv Ltd. | In-service software/firmware update |
US11741232B2 (en) | 2021-02-01 | 2023-08-29 | Mellanox Technologies, Ltd. | Secure in-service firmware update |
US11880676B1 (en) * | 2022-09-27 | 2024-01-23 | Rockwell Automation Technologies, Inc. | Containerized modeling of device updates or modifications via digital twins |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7383405B2 (en) | 2004-06-30 | 2008-06-03 | Microsoft Corporation | Systems and methods for voluntary migration of a virtual machine between hosts with common storage connectivity |
US8200787B2 (en) | 2006-12-29 | 2012-06-12 | Sap Ag | Methods and systems for distributing software |
US8191063B2 (en) | 2007-09-30 | 2012-05-29 | Symantex Corporation | Method for migrating a plurality of virtual machines by associating files and state information with a single logical container |
US8200634B2 (en) | 2008-10-08 | 2012-06-12 | Sap Ag | Zero downtime maintenance using a mirror approach |
US20160342510A1 (en) * | 2012-01-17 | 2016-11-24 | Google Inc. | Remote management of data planes and configuration of networking devices |
US8966467B2 (en) * | 2012-04-30 | 2015-02-24 | Dell Products, L.P. | System and method for performing an in-service software upgrade in non-redundant systems |
US8782632B1 (en) * | 2012-06-18 | 2014-07-15 | Tellabs Operations, Inc. | Methods and apparatus for performing in-service software upgrade for a network device using system virtualization |
CN103843285B (en) * | 2013-11-14 | 2017-02-08 | 华为技术有限公司 | Method of version upgrade of network device and network device |
US20170052807A1 (en) | 2014-02-20 | 2017-02-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods, apparatuses, and computer program products for deploying and managing software containers |
US20160364231A1 (en) * | 2015-06-10 | 2016-12-15 | Telefonaktiebolaget L M Ericsson (Publ) | Method for minimal service impact during software upgrade in network elements (nes) |
US10289398B2 (en) * | 2015-09-26 | 2019-05-14 | Cisco Technology, Inc. | In-service upgrade of kernel loadable modules |
-
2016
- 2016-07-06 US US15/203,583 patent/US9870219B1/en not_active Expired - Fee Related
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180053001A1 (en) * | 2016-08-16 | 2018-02-22 | International Business Machines Corporation | Security fix of a container in a virtual machine environment |
US10460113B2 (en) * | 2016-08-16 | 2019-10-29 | International Business Machines Corporation | Security fix of a container in a virtual machine environment |
US20180121189A1 (en) * | 2016-10-28 | 2018-05-03 | Parallels International Gmbh | System and method for upgrading operating system of a container using an auxiliary host |
US11403086B2 (en) * | 2016-10-28 | 2022-08-02 | Virtuozzo International Gmbh | System and method for upgrading operating system of a container using an auxiliary host |
CN108804129A (en) * | 2018-05-31 | 2018-11-13 | 新华三技术有限公司 | A kind of method for upgrading software and device |
CN108984195A (en) * | 2018-06-27 | 2018-12-11 | 新华三技术有限公司 | A kind of method for upgrading software and device |
CN113660123A (en) * | 2021-08-16 | 2021-11-16 | 杭州朗和科技有限公司 | Virtual switch upgrading method and device, electronic equipment and storage medium |
US20230103223A1 (en) * | 2021-09-24 | 2023-03-30 | Sap Se | Cloud application management using instance metadata |
US11841731B2 (en) | 2021-09-24 | 2023-12-12 | Sap Se | Cloud plugin for legacy on-premise application |
US11922163B2 (en) | 2021-09-24 | 2024-03-05 | Sap Se | Cloud version management for legacy on-premise application |
US20240022472A1 (en) * | 2022-07-13 | 2024-01-18 | Dell Products L.P. | Systems and methods for deploying third-party applications on a cluster of network switches |
Also Published As
Publication number | Publication date |
---|---|
US9870219B1 (en) | 2018-01-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9870219B1 (en) | Mechanisms for performing switch upgrades using remote containers | |
CN107580083B (en) | Method and system for allocating IP addresses of containers | |
US11429369B2 (en) | Distributed upgrade in virtualized computing environments | |
US20170024224A1 (en) | Dynamic snapshots for sharing network boot volumes | |
US10116735B2 (en) | Service migration across cluster boundaries | |
US20180212896A1 (en) | Distributed hybrid cloud orchestration model | |
US10142346B2 (en) | Extension of a private cloud end-point group to a public cloud | |
US10728084B2 (en) | Virtualized rack management modules | |
EP3617877A1 (en) | Cloud migration | |
CN108073423B (en) | Accelerator loading method and system and accelerator loading device | |
EP3021223B1 (en) | Method for enhancing memory fault tolerance | |
CN105700944A (en) | Online migration method and device for virtual machine not in shared storage condition | |
US10599532B2 (en) | Upgrade backup in virtualized computing environments | |
US10742489B2 (en) | Validating network configuration using shadow databases | |
US10931581B2 (en) | MAC learning in a multiple virtual switch environment | |
US10949234B2 (en) | Device pass-through for virtualized environments | |
EP3439249A1 (en) | Network system, management method and device for same, and server | |
US10171292B1 (en) | Deploying a cloud infrastructure in a remote site | |
CN111741102B (en) | Upgrading method and device for distributed micro-service application | |
US11372636B2 (en) | Live updating a virtual machine virtualizing physical resources | |
EP3438823B1 (en) | Control method and control apparatus for network system, and server | |
US20130081007A1 (en) | Providing continuous application availability during application update | |
US20220405171A1 (en) | Automated rollback in virtualized computing environments | |
US20230137273A1 (en) | Cloud network mechanism driver migration | |
US20240028375A1 (en) | Control plane lifecycle management with dpu devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MANTHIRAMOORTHY, NATARAJAN;SRINIVASAN, VENKATESH;NARAYANAN, SWAMINATHAN;AND OTHERS;SIGNING DATES FROM 20160607 TO 20160609;REEL/FRAME:039089/0726 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20220116 |