News

contact@portaone.com

Toll-free calls (phone & Skype)
+1 866 747 8647
Calls & faxes from abroad:
+1 604 628 2508

PortaOne, Inc.
Suite 408, 2963 Glen Drive
Coquitlam, BC, V3B 2P7
Canada

29 April 2010

PortaSwitch Maintenance Release 21 Uses an Innovative New Version Updating Process with the Introduction of Configuration Server

With MR21, PortaSwitch utilizes an innovative system of maintaining and modifying the software code on each server, allowing service providers to properly address all potential upgrade issues, and enables to:

  • Migrate quickly to a new maintenance release, without any problems on the way and obtain the system that operates 100% according to how it is intended to operate.
  • Safely rollback to exactly the same version of the software used prior to the update, in case there are any issues with the functionality of the new release.

PortaSwitch deploys a dual software version management system that eliminates both the risk of incompatibility between the updated components and dangerous situations when the update fails and the system ends up without any operable software becoming totally unusable.

The disk subsystem on each PortaSwitch server contains 3 separate partitions:

  • One partition stores the actual application data.
  • Two other partitions are equal in size and can contain the full set of the software “code” required to operate the server: operating system, third-party libraries and modules and the actual code for a specific application.
At any given moment one of 3 partitions is considered active: upon the start-up, the server uses this specific partition to boot up while the application code, located within it, is used to operate the service.

When the system is being prepared for an update to a new release, another partition is cleared and the new version of the code is installed there. This is done while the system is still operating under the current version of the software, without any service interruption.

As a result, the server has all required data to operate with the new release – moreover, since the new release is installed as a set of binary packages, it ensures that this is exactly the same code (the same version of operating system, the same version of kernel and the same bytes in every single utility or file!) that was used in PortaOne’s labs during the testing period, that was deployed on staging systems during the field testing, and that is currently being used by other PortaOne customers worldwide.

The configuration agent updates the “local” files based on the system’s configuration stored in the configuration server. At the specific time the new partition is automatically marked as “active” the server is restarted using the new version of the code. The potential downtime is minimal, just to complete the restart. Nothing is changed in the “old” partition. So if a rollback is required, it only requires a reboot from that partition and the server is back to the old, “stable” release.
                                                                                                        
Updating Process










After some time when an update to an even newer release is desired, this partition is wiped clean and the new version of the code is loaded into the recently emptied location. Then the process described above repeats. The same process is used to update to a new maintenance release or to a newer software build within the current release.

PortaSwitch relies on a large set of previously accumulated data to make decisions about how the service should be provided. All the data accumulated by the old software release are available to the new one after the upgrade to ensure the system’s proper operation. This involves changing the data files, database structures and data to accommodate the new release. Therefore, the update process includes 2 extra steps:

  • Non-blocking data modifications are done as part of the “preparation” process, when the new release is already installed to the new partition, but before it becomes active.
  • Blocking data modifications are those that may affect the system’s performance while they are being carried out. Therefore, those are done during off-peak periods.

This process allows the data modifications to be performed while the system still operates using the current release. During that time, the “older” version of the release operates with the “newer” version of the data. The same situation would happen if in performing a rollback to the older release. The PortaOne development and testing processes are specifically aimed to make this possible however we can only guarantee this inter-operability for the adjoining releases.

Please find more detailed information about the new updating process in PortaBilling Administrator Guide (look for Updating the System to a New Version section on page 17). This MR21 guide is available on the Documentation page along with other constantly renewed handbooks and manuals.


 

Superb Reliability and Scalability with
24/7 Professional Technical Support

icon1.png

Open architecture

PortaOne provides both APIs and source code for PortaSwitch to allow an easy integration
 
icon2.png

Scalability for growth

Our platforms can easily scale up by adding more servers to match your project success
 
icon3.png

Reliability and redundancy

Clustering and geo-redundant site configuration allow to address the most rigorous requirements
 
icon4.png

Constant improvement

The dedicated highly skilled development team delivers more than 20 software builds per year
 
icon5.png

24/7 technical support

Over 60% of our 300 engineers are in the technical support services, praised as the best in industry