The Cape Higher Education Consortium (CHEC) manages Calico, a Library Management System for the four Western Cape Universities. This system ran on physical servers in the Internet Solutions Datacenter. The hardware became very expensive to maintain, and when three of the universities indicated they would be migrating to the cloud-based version of the software within the next 12-18 months, it became clear the current setup would need to be revisited.
CHEC approached UCT for assistance, and we proposed to virtualise the Calico infrastructure. Given the high availability requirements, the team (notably Waylon and Abraham), with some excellent project management from Leon Alexander, managed to do a P2V (Physical to Virtual) conversion, and ensured a successful cut-over this past weekend.
The development, production and warehouse environments are now running fully virtualised in a DMZ on ICTS’ VMware infrastructure.
Feedback from the libraries has been very positive, and we are happy to have been part of this project.
The below post by Waylon Horne:
Quick Steps to F5 BIG-IP LTM 11.x Virtual Edition High Availability
Acting as a reverse proxy and distributing network and application traffic amongst numerous servers is just the tip of the iceberg when it comes to the F5’s many features.
With today’s increasing demand for capacity, the F5 is becoming one of the most crucial devices in the networking jungle.
And with this demand, it’s only logical that it should be configured to be always available, hence the quick steps below to help you configure your F5 for HA.
- You must have a dedicated VLAN for HA.
- You must have Self-IP’s configured for both the HA VLAN network and Management network on both devices.
- These steps assume that you have setup the necessary defaults such as DNS, NTP, Admin Password, VLANS, etc.
2: HA VLAN setup:
- Login at https://YourLTMApplianceIP Enter the admin username/password.
- Go to Network > VLAN > VLAN List. Click
- Enter name
- Select 1.3 for interface, Tagging Click the Add button.
- Repeat the same steps as above on Appliance B.
3: Self IP setup:
- Go to Network > Self IPs. Click Create
- Type Name as SIP-HighAvailability. IP Address 0.0.1. Netmask as 255.255.255.0. VLAN as HighAvailability. Port lockdown Allow All. Select the Default Traffic Group (non-floating).
- Repeat the same steps as above on Appliance B using 0.0.2 as the IP.
- Click Finished.
4: Getting ready for HA setup:
- On Appliance A go to Device Management > Devices > Device Connectivity > Config Sync. Select the0.0.1(HighAvailability) VLAN IP.
- On Appliance A go to Device Management > Devices > Device Connectivity > Failover Network. Click Addunder Failover Unicast Configuration. Select your Management IP here.
- Repeat the same steps as above on Appliance B using Appliance B’s HA and Management IP.
5: HA cluster setup:
- On Appliance A go to Device Management > Device Trust > Peer List. Click Use the Management IP of Appliance B and admin username/password. Follow the rest of the steps
- Both appliances should now be paired with each other.
- On Appliance A go to Device Management > Device Groups. Click Create.
- Type name as SyncFailover to identify the device group which will participate in failover cluster.
- Group Type is Sync-Failover.
- Drag both IPs from right to left.
- Select Full Sync and Network Failover (leave Automatic Sync Unchecked).
- On Appliance A go to Device Management > Overview and select SyncFailover under Device Groups
- Select Appliance A under Devices, then select Sync Device to Group as well as the ticking the Overwrite Configuration check box. Click Sync.
- You HA cluster Setup is now complete. One appliance will now show as ACTIVE and the other one STANDBY.
More HA troubleshooting tips can be found on F5’s support KB article “SOL13946: Troubleshooting ConfigSync and device service clustering issues (11.x)”
Since 2010 when we started moving our student email system to (then) Live@edu, I think we’ve learned quite a bit… I thought I’d share some of our experiences and (of course!) my own opinions, this being Part I….
The pace at which cloud providers (read: Microsoft & Google) are making changes and improvements to the functionality provided, is simply staggering compared to what an internal IT dept of a university could do. That does of course present us with a number of challenges, and I mention a couple of examples:
- Integration with our on-premise systems: Cloud providers often integrate new products into the core suite (example: Yammer with Sharepoint Online), which opens up some real interesting conundrums. If we activate SSO (Single sign on) to a cloud application, some users might have subscribed to the product using their institutional email address, but with a different password. This happened with Google Docs when we on-boarded our @uct.ac.za domain into Google Apps for Education.
- End-user support: It is very likely that a user will be using a specific function, maybe via a mobile app, way before any IT person is doing so. In the BYOD (bring your own device) world, users have access to Android & Apple apps, with associated access to back-end functionality not exposed by our on-premise systems. They expect us to support the application irrespective of origin, version or release date.
- Training & documentation: The traditional model calls for us to have our training and documentation up-to-date and ready before a product or service is launched. This is becoming increasingly difficult, and we now end up linking to the vendor’s information directly. Of course this also means freeing up some time of technical writers 😉
So off we ride (fly?) into the cloud(s)…
ICTS hosted five members from NWU IT. We shared ideas, solutions and (anecdotes), and I found it refreshing to see how similar challenges are being addressed in response to institutional requirements.
Some of the topics covered were around datacenters, compute, virtualisation, storage and Disaster recovery.
See what they are up to: http://www.nwu.ac.za/ithome
We will be moving ICTS staff mailboxes from on-premise Exchange 2010/2013 servers to the Office 365 Datacenter (in Europe…), next week. We hope to use this as a final test before we start with the rest of the 9000-odd mailboxes.
A lot of work and preparation went into this project, and after this is done, the only box to be ticked will be to migrate away from Mailman as our mailing list software.