First, the Domain Controller (trenton) needed a 2nd NIC card and an assignment to the gig-e network. Once in place, DNS was updated manually to reflect the 10.x address (DNS is running on this DC).
Since the move to the equipment closet will mean that all internet traffic from vSphere will need to be forwarded to the new NAT server, the network card gateway was set to point at cape-may. The DNS setting would point at itself.
Once these changes were made, all domain traffic will go over Gig-e. It will cause all other domain members to be confused until their NIC card and DNS configurations were updated.
Tomorrow....
Sunday, November 28, 2010
Moving vSphere hardware - #2
So we were aware that to move the vSphere hardware would require moving all network traffic to the Gig-e network. The biggest issue here is that Windows Active Directory and it's DNS were built on the local LAN.
Also in the plan is to move the ESXi hypervisor networks, as these were built on the LAN as well.
A little planning was needed in order to gracefully move the core VM's to Gig-e. Also, not all domain members were built with dual NIC cards.
Also in the plan is to move the ESXi hypervisor networks, as these were built on the LAN as well.
A little planning was needed in order to gracefully move the core VM's to Gig-e. Also, not all domain members were built with dual NIC cards.
Saturday, November 27, 2010
Proof of Concept NAT Server
To validate the NAT scenario, a Ubuntu server VM was created called cape-may. This is just the CRM standard Ubuntu build, with IP forwarding and IP Tables configured.
One NIC card on cape-may is connected to the internal LAN while a 2nd NIC was placed on the dvs-Production distributed switch (Gig-e). Client devices that need access to the LAN and internet can be placed on dvs-Production with a gateway address of cape-may on gig-e and a DNS setting of the LAN switch.
Some preliminary testing using the Win2k VM win2kmove validated the config quickly. Both ping access and web browser internet is functioning. It is important to add the DNS entry on the client, since that is how internet names are resolved. This will become more complicated once AD is moved (more on this later).
In the equipment closet configuration, the LAN card will probably be a USB wireless network adapter.
The next step is to configure VMware Tools on cape-may to get better throughput by loading the Tools' NIC drivers. This will happen in the next week or so.
The other item that needs testing is the ingress access which is required to get to the vCenter and ESX servers. This might require additional configuration on the NAT server.
One NIC card on cape-may is connected to the internal LAN while a 2nd NIC was placed on the dvs-Production distributed switch (Gig-e). Client devices that need access to the LAN and internet can be placed on dvs-Production with a gateway address of cape-may on gig-e and a DNS setting of the LAN switch.
Some preliminary testing using the Win2k VM win2kmove validated the config quickly. Both ping access and web browser internet is functioning. It is important to add the DNS entry on the client, since that is how internet names are resolved. This will become more complicated once AD is moved (more on this later).
In the equipment closet configuration, the LAN card will probably be a USB wireless network adapter.
The next step is to configure VMware Tools on cape-may to get better throughput by loading the Tools' NIC drivers. This will happen in the next week or so.
The other item that needs testing is the ingress access which is required to get to the vCenter and ESX servers. This might require additional configuration on the NAT server.
Moving vSphere hardware
It has been a plan for sometime to move the vSphere hardware out of the lab and into one of the equipment closets. One of the issues with this plan has been how to get LAN access to the equipment closets, as well as internet access.
Short of running additional cables, a NAT Linux server with a wireless NIC should be able to forward traffic to the lab LAN and on to the internet. Obviously, the production instance will need to be real hardware since VM's don't support things like USB network adapters.
Short of running additional cables, a NAT Linux server with a wireless NIC should be able to forward traffic to the lab LAN and on to the internet. Obviously, the production instance will need to be real hardware since VM's don't support things like USB network adapters.
New Win7 x64 desktop
It has been a while but some progress has been made. The Dell 745 has been installed with Win7 x64 (6 GB memory) and is now the primary workstation. The HP laptop is in it's case (where it belongs), ready for customer site travel.
The dual monitor set up has been transferred to this environment, using the Dynadock.
The faster performance of the 64 bit platform and extra memory is very noticeable.
The dual monitor set up has been transferred to this environment, using the Dynadock.
The faster performance of the 64 bit platform and extra memory is very noticeable.
Wednesday, October 13, 2010
New Win7 x64 desktop
This new primary workstation is close to being ready for production.
One item at issue is the amount of traffic on the 100Mbps front end network. When performing installs, doing testing, and maintenance on vSphere components and VM's, this front end network becomes very congested.
The plan is to move all vSphere management, Active Directory, and storage traffic to the back door gig-e and run VMware Workstation on the new Win7 workstation for all management access to vSphere. This will ensure that only internet bound VMware traffic will travel over the slower network.
One item at issue is the amount of traffic on the 100Mbps front end network. When performing installs, doing testing, and maintenance on vSphere components and VM's, this front end network becomes very congested.
The plan is to move all vSphere management, Active Directory, and storage traffic to the back door gig-e and run VMware Workstation on the new Win7 workstation for all management access to vSphere. This will ensure that only internet bound VMware traffic will travel over the slower network.
Tuesday, October 5, 2010
Issues with the vCenter Server
Attempting to log into vCenter, the cluster is unable to be found and an error is presented stating that VUM (VMware Update Manager) cannot be contacted.
Initial troubleshooting plan is to log out of vCenter and directly into northvale, log directly into alpine (win2k8 box housing vCenter) and check the logs to make sure these are no obvious errors. The only error is a Winlogon application error for GPClient.
More digging. Shutting down vCenter VUM services on alpine and moving to red-bank to ensure SQL Server is happy.
First step is to push all new Windows Updates to red-bank, and rebooting. The errors persist.
red-bank event logs were showing logon errors for a system request along with a SQL scheduled job failing for a database. It was not long before we determined that this is a task for a database that is no longer present.
After removing the task from SQL Management Studio, the errors are gone. We will give the SQL server 30 minutes or so to ensure the errors do not return before restarting vCenter and VUM services on alpine.
Initial troubleshooting plan is to log out of vCenter and directly into northvale, log directly into alpine (win2k8 box housing vCenter) and check the logs to make sure these are no obvious errors. The only error is a Winlogon application error for GPClient.
More digging. Shutting down vCenter VUM services on alpine and moving to red-bank to ensure SQL Server is happy.
First step is to push all new Windows Updates to red-bank, and rebooting. The errors persist.
red-bank event logs were showing logon errors for a system request along with a SQL scheduled job failing for a database. It was not long before we determined that this is a task for a database that is no longer present.
After removing the task from SQL Management Studio, the errors are gone. We will give the SQL server 30 minutes or so to ensure the errors do not return before restarting vCenter and VUM services on alpine.
Subscribe to:
Posts (Atom)