I’m starting the upgrade to Ubuntu 8.10 on my Linux desktop so I’ll be using my laptop for most of the day. Hopefully the download of 1216 packages goes quickly, and I’ll just have to swing by and click a next or an OK every once in a while.
F5 LTM Hardware: The F5 hardware for the Hill and Stevenson data centers and been racked. The F5 hardware for the VUH data center has been shipped to the MC campus, and the installation/configuration is pending the administrative details of getting IP addresses and firewall configuration completed. The Hill hardware has been configured and is waiting on the installation of the network firewall to complete network connectivity on all sides.
Sun Identity Management: The F5 hardware installation was a big step towards bringing the new ELDAP and CLDAP services online. I have scheduled the pre-approved changes to add the backend VLAN to each ESX server. Once this is complete, I’ll move the allocated production VMs over to F5 backend network, and reconfigure the network settings on each.
ITS Website Redesign: The design elements of the website redesign are nearly complete, and the initial changes have been scheduled to stage the necessary server hardware.
SiteMason Patching: The SiteMason database server has been patched to current RHEL4 standards. During the server reboot, I discovered that the previously running database configuration defaults did not match the previously live running parameters. I had to adjust several kernel parameters to adjust the memory configuration to get the PostgreSQL service to start. I have been also monitoring the system to see I if can alleviate some performance problems on the web server; however, this has been difficult with the unscheduled changes to the SiteMason code.
CSM Configuration Enhancements: I have implemented two successful test configurations on the CSM that allow servers behind the CSM to connect to other load balanced services. I’ve documented the test configuration and uploaded it to Sharepoint. This configuration template will be applied to all of the CSM load balanced services to ensure full connectivity. The configuration will effectively double the size of the CSM configuration file; however, it will also negate the need to local host file entries on the servers.
I just finished reading Verbal Judo: The Gentle Art of Persuasion. It is a very fast read, and it reminds me of another book that I had read in the past, specifically Way of Aikido: Life Lessons of an American Sensei. Both books deal with applying martial arts concepts to everyday life situations. This book had a few more acronyms and process enumerations, but it was a rather easy read. One of the key points of Verbal Judo is being empathetic with the person that you are communicating with, while the focus of the Aikido book was situational awareness. While I have never studied the Judo or Aikido as a martial art, I have studied Tai Chi for a while. For those that are unfamiliar with Tai Chi, it also encompasses the concepts of awareness and energy redirection. One of key concepts in Tai Chi is rooting, which is the basis for a solid foundation and balance. I’ve always tried to make a conscious effort to utilize these in my communications. In any event, I think Verbal Judo is a good conceptual book, and I’m going to try to float it around to my coworkers.
This morning I put together the finishing touches on a CSM configuration that may solve some of our connectivity issues. We currently have an issue where servers in one server farm are not able to communicate with services in other server farms due to a routing loop. As expected, the listening server responds directly to the connecting client (since the are on the same instead of communicating back through the VIP address.
I made multiple calls to the Cisco TAC, and I provided them with our current running configuration and desired end result. Unfortunately, I was not able to get a working configuration from them that met our needs. One Cisco engineer even told me that it was not possible to get what we wanted.
Luckily I did have other options to pursue like creating an internal vservers on the server network. Going this route would probably fix our issue, but it introduces an early dependancy on service that is still in the process of being deployed. I managed to find a working configuration that allows both traditional client-server communications as well as server-server communications.
The configuration that I have in test involves expanding our singel serverfarm and vserver to two serverfarms, two vservers, and a natpool. By manipulating the allowed/excluded VLANs and IP ranges to each, it’s possible to create two services points answering on the same IP address and port combination. This is definitely preferable to the AppHosting team since it means that we don’t have to worry about duplicate service points, split DNS, and such. If I get some time, I’ll generalize the document that I created for my team and post it up here for the world to see.
