The upgrade of the system is the last thing any school information centre would want to do, but sooner or later.——There are always reasons to change you. But unlike a new core switch, the cut-off of the billing system and any error in any of the middle means that tens of thousands of people cannot be connected to the Internet. The entire teacher/student online service cannot be considered a night-time slash window gambler. I have seen successful cases, as well as the two days of tragedy caused by the failure of the cutting.
Three things you have to confirm before cutting, and none of them move.
First thing: integrity and portability of user data. Whether the old system's user data can be fully exported and the format properly interpreted by the new system is the basis for cutting. Many old system accounts are scattered in several tables: basic information on users is on the user table, a package is on the page_binding table, balance is on the account_balance table, real name authentication information is on the realname_auth table, Internet log is on the Radius_log table——The relationships between these tables are not necessarily bound by standard external keys, sometimes maintained by the application logic. If the export tool is simple select, it may be lost data. So it takes time to do a full-data check before cutting, contrasting old and new system fields with which field is missing or where type of field is not matched, and you have to write it in advance and figure out how to convert it.
Second thing: Compatibility of authentication protocols. The campus network billing system has only one entry for users, i.e. the certification page. Whatever your backstage is changed, the process of opening a browser to WiFi and jumping to Portal pages cannot change. If the old system Portal servers and RADIUS servers are deployed separately, then you can consider keeping Portal still when cut, cutting back end RADIUS billing engines, and the user-side certification experience is completely unchanged. When the new system runs smoothly, you can then cut Portal in batches.
Third thing: Synchronizes the configuration of the export equipment. Many failures in cutting are not due to the system itself, but rather to its interface with core network equipment. Once the new system is online, all parameters for RADIFUS server addresses on BRAS or AC, share secret, bill update intervals, COA ports will have to be changed. The wrong change or missing will result in a certified page opening, but a point entry will always rotate. So there must be a detailed list of changes in network configurations within the cut-off programme, how each device will be modified and when it returns, and it will be clear that no one will be expected to turn the equipment over the day.
Three cutting strategies. Risks and costs are different.
The first is..."One-time full cut"Select a night-deep window to cut all users, all equipment, and all configurations into the new system. The advantage is clean and clean, with no associated maintenance costs for old and new systems. The disadvantage is that risk concentration, and any link blows directly.
The second is..."Bulk Migration", cut a group of test users or volunteers for one to two weeks and confirm that there is no big problem before switching. The advantage is risk dispersion, the new system first being tested for small-scale real scenes. The disadvantage is that two systems need to be maintained simultaneously, and there may be problems with data synchronization between the two systems.——The old system continues to charge, the new system is also charging, and what if it does not match?
The third is..."The old and the new run in parallel.", retain all the configurations of the old system and deploy a complete Authentication & Billing link independently of the new system, channeling some user traffic to the new system through an export route strategy. When the new system runs a full costing cycle (usually one month) to confirm that the account data is fully aligned, it will be offline. This is the surest way to double hardware resources, requiring two RADIUS and two Portals running simultaneously.
The one that had to be back on the day of the cut.
Whatever strategy you choose, cutting the rollback plan is a bottom line. The key to rolling back is not"Just turn off the new system."The old system must be able to return immediately to pre-cut. This means that before the cutting starts, the older system will have to make a full configuration backup and database snapshots, including RADIFUS configuration, Portal configuration, user data, menu rules, billing strategies, and all current network device operation configurations (running-config) will also need to be backed up. If a large area certification fails within 10 minutes of the new system being online, roll back immediately: network equipment is restored to old configuration, DNS points Portal domain back to an old server IP, the old system is activated from quick-record.
The biggest difficulty in rolling back is data regression: when the new system is online, users are authenticating and billing, do they want to keep the newly generated data? If not, these users need to re-validate it, creating a wave of centralized passenger calls. If retained, there is also a risk that the new data will be quickly fed back into the old system before rolling back.
Observation period after slicing
Many schools feel that the cut is successful and that the whole school can be connected to the Internet. The first fee cycle after the cut is actually a real acceptance period. There are at least three things to look into this cycle: first, whether there are any anomalies in the end-of-day reconciliation reports and the balance is being carried forward, second, whether the switchover is normal, especially if the conversion logic of the monthly switch is normal; third, whether the batch operation (distributors, lot charge) will run normally on the new system at the end of the month.