Azure Stack Hub ruggedized network configuration lifecycle management
This topic covers lifecycle management for network configuration.
A methodology for updating switch configurations in the field. This applies to all and any type of configuration updates. Due to many unknown variables outside of our control, like manual configurations applied by customers or by the OEM this will be a multi-step manual process. At this time there is no guarantee of uptime and updates should be performed during a maintenance window.
#1 - Make a backup of the current configuration files for tor1, tor2 and BMC switches. Copy these files off the switch.
#2 - Make a note of the toolkit build number of the existing configuration. All configurations should have this in the motd banner. Do a search for "BUILDNUMBER"
#3 - Regenerate the initial configurations using the same toolkit version from step #2.
#4 - Load the configurations from step #3 onto their respective switches. The point of this is to wash the config generated by our tools through a switch to get a baseline. This could be performed by the OEM on separate hardware, like in the OEM’s lab, or onsite with the customer.
#5 - Make a backup of the config file from step #4 and copy it to a remote location
#6 - Using to the diff tool of your choice compare the backup of the current config from step #1 to the backup of the baseline configuration from step #5. Make a note/copy of all the differences that should be carried over to the upgraded switch configuration per device.
#7 - Run the new toolkit that will generate the updated switch configurations.
#8 - Merge the differences from step 6 into the new switch configurations.
#9 - Load the new configurations onto the respective switches and run the post validation commands provided in the output directory from our tooling.
#10 - Save the configurations.
You can use the privileged endpoint (PEP) to update the time server in Azure Stack. Use a host name that resolves to two or more NTP server IP addresses.
Azure Stack uses the Network Time Protocol (NTP) to connect to time servers on the Internet. NTP servers provide accurate system time. Time is used across Azure Stack's physical network switches, hardware lifecycle host, infrastructure service, and virtual machines. If the clock isn't synchronized, Azure Stack may experience severe issues with the network and authentication. Log files, documents, and other files may be created with incorrect timestamps.
Providing one time server (NTP) is required for Azure Stack to synchronize time. When you deploy Azure Stack, you provide the address of an NTP server. Time is a critical datacenter infrastructure service. If the service changes, you will need to update the time.
Azure Stack supports synchronizing time with only one time server (NTP). You cannot provide multiple NTPs for Azure Stack to synchronize time with. It is recommended to setup DNS entry that resolves to multiple NTP servers.
Update NTP post deployment
Connect to the privileged endpoint (PEP). You don't need to open a support ticket to unlock the privileged endpoint. |
Run the following command to review the current configured NTP server:
Run the following command to update Azure Stack to use the new NTP Server and to immediately synchronize the time:
Set-AzsTimeSource -Timeserver NEWTIMESERVER -resync
This procedure doesn’t update the time server on the physical switches.
Update the DNS forwarder in Azure Stack
At least one reachable DNS forwarder is necessary for the Azure Stack infrastructure to resolve external names. A DNS forwarder must be provided for the deployment of Azure Stack. That input is used for the Azure Stack internal DNS servers as forwarder, and enables external name resolution for services like authentication, marketplace management, or usage.
DNS is a critical datacenter infrastructure service that can change, and if it does, Azure Stack must be updated.
This article describes using the privileged endpoint (PEP) to update the DNS forwarder in Azure Stack. It is recommended that you use two reliable DNS forwarder IP addresses.
Connect to the privileged endpoint (PEP). You don't need to open a support ticket to unlock the privileged endpoint.
Run the following command to review the current configured DNS forwarder. As an alternative, you can also use the admin portal region properties:
Run the following command to update Azure Stack to use the new DNS forwarder:
Set-AzsDnsForwarder -IPAddress "IPAddress 1", "IPAddress 2"
Review the output of the command for any errors.