Azure public IP addresses now support the ability to be upgraded from Basic to Standard SKU. Additionally, any Basic Public Load Balancer can now be upgraded to a Standard Public Load Balancer, while retaining the same public IP address. So what could be the reason to change the SKU.
First the Difference and the price between Standard and basic
Standard
Standard SKU public IP addresses:
- Always use static allocation method.
- Have an adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and fixed outbound originated flow idle timeout of 4 minutes.
- Secure by default and closed to inbound traffic. Allow list inbound traffic with a network security group.
- Assigned to network interfaces, standard public load balancers, or Application Gateways. For more information about Standard load balancer, see Azure Standard Load Balancer.
- Can be zone-redundant (advertized from all 3 zones) or zonal (can be created zonal and guaranteed in a specific availability zone). To learn more about availability zones, see Availability zones overview and Standard Load Balancer and Availability Zones. Zone redundant IPs can only be created in regions where 3 availability zones are live. IPs created before zones are live will not be zone redundant.
- Can be used as anycast frontend IPs for cross-region load balancers (preview functionality).
Cost of single IP Sample
Basic
All public IP addresses created before the introduction of SKUs are Basic SKU public IP addresses.
With the introduction of SKUs, specify which SKU you would like the public IP address to be.
Basic SKU addresses:
- Assigned with the static or dynamic allocation method.
- Have an adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and fixed outbound originated flow idle timeout of 4 minutes.
- Are open by default. Network security groups are recommended but optional for restricting inbound or outbound traffic.
- Assigned to any Azure resource that can be assigned a public IP address, such as:
- Network interfaces
- VPN Gateways
- Application Gateways
- Public load balancers
- Don’t support Availability Zone scenarios. Use Standard SKU public IP for Availability Zone scenarios. To learn more about availability zones, see Availability zones overview and Standard Load Balancer and Availability Zones.
Cost of single IP Sample
With this Standard seems to have more and better options but is 1 euro more expensive So you could think Always use standard But A public IP address is assigned to the VPN Gateway to enable communication with the remote network. You can only assign a dynamic basic public IP address to a VPN gateway.
So it really depends on what you want to use, suppose you start with basic and need standard you can change this now with PowerShell or cli but not in the GUI
Limitations
- In order to upgrade a Basic Public IP, it cannot be associated with any Azure resource. Please review this page for more information on how to disassociate public IPs. Similarly, in order to migrate a Reserved IP, it cannot be associated with any Cloud Service. Please review this page for more information on how to disassociate reserved IPs.
- Public IPs upgraded from Basic to Standard SKU will continue to have no availability zones and therefore cannot be associated with an Azure resource that is either zone-redundant or zonal. Note this only applies to regions that offer availability zones.
- You cannot downgrade from Standard to Basic.
In my fresh created IP called demo We change this to a standard IP address
Using the portal to run some powershell commands.
## Variables for the command ##
$rg =”rg-demo-weu-01”
$name = “demo”
$newsku = ‘Standard’
$pubIP = Get-AzPublicIpAddress -name $name -ResourceGroupName $rg
basic resource group and IP address name
## This section is only needed if the Basic IP is not already set to Static ##
$pubIP.PublicIpAllocationMethod = ‘Static’
Set-AzPublicIpAddress -PublicIpAddress $pubIP
## This section is for conversion to Standard ##
$pubIP.Sku.Name = $newsku
Set-AzPublicIpAddress -PublicIpAddress $pubIP
Fixed IP address SKU changed from Basic to Standard. Remember there is no option to undo this.
Now testing with an used IP and connected to an VM. ( this VM is currently deallocated) as these changes can only be done offline.
With this the resource changed from basic to Standard.
Try to undo this then the following message is there
Set-AzPublicIpAddress -PublicIpAddress $pubIP
Set-AzPublicIpAddress: Sku property is set at creation time and cannot be changed from Standard to Basic on resource update for resource
Changing the SKU is a nice option, that way you can keep the IP and lift the needed options with zero downtime.
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
This Holiday Season, WIN with Altaro!
‘Tis the season to be caring – caring for your loved ones, for each other, and yes, even your data and mailboxes. The arrival of the Holiday Season is a great time to recognize all the challenges we’ve survived this year, to be thankful for all we have and to share.
If you use Microsoft 365/Office 365, Hyper-V or VMware, celebrate with Altaro. All you have to do is sign up for a 30-day free trial of either Altaro VM Backup or Altaro Office 365 Backup – it’s your choice!
How does it work?
· Trial Altaro VM Backup or Altaro Office 365 Backup
· Get a guaranteed $10 Amazon voucher & a chance to win one of the Grand Prizes
· Altaro will make a $10 donation to One Laptop per Child for every valid entry
What are you waiting for? Sign up now!
Like this:
Like Loading...
Azure Data Box Gateway Where is the difference between Azure Files Sync or Azure file share or even a StorSimple now a Data Box. As you may know a Azure Data box the the ultimate device to bring data fast to the Azure Cloud.
This blog was long pending as I did many Azure migrations and new stuff came up every time. Now that there is a Azure Data Box Gateway that you can run on your favorite hypervisor Hyper-V you can create a virtual instance to bring your data to a Azure storage account. Now days there is a lot of overlap in products.
- Azure Files (Sync) sync’s your data to an Azure Storage account – Auto Sync.
- Azure files uses Net use to connect to a storage account – Manual copy and writes direct to Azure
- StorSimple (old but still seen in the wild)
- Azure Data Box Gateway
One of the primary advantages of Data Box Gateway is the ability to continuously ingest data into the device to copy to the cloud, regardless of the data size. Keep in mind this is not a file server replacement. but my first impression is this could replace a storsimple as this may not the goal for this. As you could run a virtual StorSimple.
As the data is written to the gateway device, the device uploads the data to Azure Storage. The device automatically manages storage by removing the files locally while retaining the metadata when it reaches a certain threshold. Keeping a local copy of the metadata enables the gateway device to only upload the changes when the file is updated. Keep in mind the Azure Storage account limits https://docs.microsoft.com/nl-nl/azure/databox-online/data-box-gateway-limits#azure-object-size-limits
there is a thin line between the products and I must say I was impressed by the speed of the upload it was fast and I could used the whole bandwidth.
So let us start building.
To create any Azure Stack Edge / Data Box Gateway resource, you should have permissions as a contributor (or higher) scoped at resource group level. You also need to make sure that the DataBoxEdge provider is registered.
In the Azure portal we go to the Data Box Gateway.
Do Add to create a new BOX below is the Databox blade and not the Gateway option
Selecting the DataBox gateway gives you the option to select the hypervisor this option is not available in the DataBox.
I used the Hypervisor
In this we pick the DataBox Gateway. the Cost are $105 per month not a big price.
We create a resource group as for all Azure resources. and a location
PAYG-Azure Sponsorship
Resource group
rg-databox-gw-001
Name
mvp-databox-gateway-001
Region
West Europe
Details above easy setup in Azure.
Now that the Azure Databox Gateway is bought in the Marketplace we can setup the device. First we need to download the VHDX file for our VM
So We download the 5GB image and use this in our Hyper-v Server
On the Download image tile, select the virtual device image corresponding to the operating system on the host server used to provision the VM. The image files are approximately 5.6 GB.
Extract the File and use the VHDX as an Gen 2 VM
Some basic specs for the VM
I played with the settings a bit to see if I could lower the VM’s Specs. You will see that later in a screenshot.
You may have to wait 10-15 minutes for the device to be ready. A status message is displayed on the console to indicate the progress. After the device is ready, go to Action. Press Ctrl + Alt + Delete to sign in to the virtual device.
The default user is EdgeUser and the default password is Password1.
Use Password1 as default password.
as you can see I used 1 CPU the setup stopped and I changed it to 8 CPU and 8 GB memory.
Now that the VM is setup we can go to the management page that runs on the IP.
Using the default password Password1
Chaning the Pasword in eh is something that you can remember
There are not much settings that you can change as time and IP and stop or reboot but the configuration is done from the Azure portal.
The one thing that is needed is to activate the VM
In the portal you can set the name and get the key.
Generate a key and use the keyvault name if you lose the key
When activating the device with the key the device is live!
There are 3 modes for the device I used the full connected setting.
There is some diagnostics in the VM and for now it all looks good.
Our Next steps are creating a share and an extra user and test some performance
We add a user that can be used to connect to the Share as it is not AD or AADDS
Our next step is to create a share
make sure the storage account where the files need to land is already created
In the Azure portal, select your Data Box Gateway resource and then go to Overview. Your device should be online. Select + Add share on the device command bar.
You’re notified that the share creation is in progress. After the share is created with the specified settings, the Shares tile updates to reflect the new share.
Connect to the SMB share
On your Windows Server client connected to your Data Box Gateway, connect to an SMB share by entering the commands:
-
In a command window, type:
net use \\<IP address of the device>\<share name> /u:<user name for the share>
Enter the password for the share when prompted.
net use * \\192.168.1.96\agwfiles001 /u:mvpadmin
now that the device is up and running we can push some data to the cloud. as the gateway is the man in the middle and the extra drive is holding the files and then transferred to Azure.
I had no limit set and I was surprised that it could eat the full line. this makes it more fun.
just a few files to test, but I need more files to test this. and let me set some bandwidth limits
Setting a limit from 200Mbps did limit the speed
Think I need to see and play a bit more as the 200 Mbps is not really working, it is more that I have still 200 Mbps over. but there is a schedule and that is really nice so these files or backup can be transferred in the night hours at high speed.
now back to no limit
yeb it is working and I think I need a bigger internet line. Remember this 
If we had Azure in these days
Deleting the files from the Gateway did not remove the files from the storage account and showed as a nice archive, If you need to copy a large amount of files than this is a great solution and cheaper than the big data box.
Some extra links to Azure Data migration
Azure Migration Center
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
In the past I build a lot of how to build stuff on a cluster or troubleshooting can’t think of any thing or I did add this on a cluster, but with Azure this whole workload went to the past.
A bit feels it that Windows server FCI is a legacy feature but is it ? well lots of items are still using this and not everyone is in the cloud.
But what if you still want to build a cluster in Azure. yes SQL – AlwaysOn is still a good and valid option. But talking a failover file server ? or some other easy workload. Well in this blog I show you how to build this cluster and the workload is up to you. For a long time it was not possible to create a FCI in Azure as there where no shared disk available and If you want to build a FCI you need some extra software from SIOS. https://us.sios.com/
In this post I create a Two node Failover Cluster FCI. with a file server role
So what do we need to build a cluster in Azure
- Two Windows server 2019 Vm’s
- atleast one Shared premium disk
- Azure Internal loadbalancer
- Some time
Building the 2 Vm’s and domain joined need no explanation, If you need help just post a comment and I will help.
Two Azure VM’s mine are deallocated for now for a reason, as we need to adjust the disk and this can only be done when the vm is deallocated.
This is just a basic VM one network card. but make sure you choose a SKU that support a Premium SSD ! with out that it won’t run and Size does matter.
In my created VM I use a 256 GB disk I may not need this size but it is the minimum supported disk for creating a cluster
Enabling shared disks is only available to a subset of disk types. Currently only ultra disks and premium SSDs can enable shared disks. Each managed disk that have shared disks enabled are subject to the following limitations https://docs.microsoft.com/en-us/azure/virtual-machines/linux/disks-shared?WT.mc_id=AZ-MVP-4025011
as you can see there is a MaxShares list For each disk, you can define a maxShares value that represents the maximum number of nodes that can simultaneously share the disk. For example, if you plan to set up a 2-node failover cluster, you would set maxShares=2. The maximum value is an upper bound. Nodes can join or leave the cluster (mount or unmount the disk) as long as the number of nodes is lower than the specified maxShares value
The maxShares value can only be set or edited when the disk is detached from all nodes that is why my VM’w are deallocated for now.
How to create such a Shared disk There are multiple ways create a disk in the disk blade. or run a powershell script it’s all up to you
creating the disk in the portal is quick and easy but it can also be done in a ARM or posh or CLI script. Personally I use often PowerShell instead of ARM.
In the Advanced options there you can enable this shared disk setting
There is no other GUI method that can set this
Or if you have already created and added this disk to a node you can create another disk on that node. But remember that does not enable the Maxshared option.
A resize does not help you.
There is no option to set this afterwards in the Portal keep that in mind. you can only set this with powershell
Sample Idea. in my case
$vmDisks1 = get-azdisk -ResourceGroupName rg-cluster01 -DiskName demo01
$vmDisks1.MaxShares=2
$vmDisks1 | Update-AzDisk
as the error show the disk need to be detached. of all machines!
Ok now that the Disk has changed or recreated and has the setting maxshared=2
We first go to node001 and add the disk to that node
Make sure you attach the same disk to both nodes as this disk was configured as a shared disk
Keep in mind creating the disk here does not enable the MaxShares
now on the second node we add the same disk as it is a shared disk you can see this now 1 used and one share is open. And remember the VM’s need to be deallocated !!
now that the disk is been added to both nodes we can start to build our cluster
After the VM’s are started we install the failover and the file server feature see also my other cluster blogs https://robertsmit.wordpress.com/2018/11/29/step-by-step-windows-server-2019-file-server-clustering-with-powershell-or-gui-cluster-ha-azure-windowsadmincenter-windowsserver2019/
Install-WindowsFeature –Name Failover-Clustering,file-services –IncludeManagementTools
or do this in the GUI. or run this from the domain member server in my case the Dc
$nodes = ("node001","node002")
Invoke-Command $nodes {Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -IncludeManagementTools}
Now building the Cluster with the wizard is not the best method. As in this case we want to set some different options than default.
The distributed network name (DNN) replaces the virtual network name (VNN) as the connection point when used with an Always On failover cluster instance on SQL Server VMs. This negates the need for an Azure Load Balancer routing traffic to the VNN, simplifying deployment, maintenance, and improving failover.
With an FCI deployment, the VNN still exists, but the client connects to the DNN DNS name instead of the VNN name.
Limitations
- Currently, a DNN with FCI is supported only for SQL Server 2019 CU2 and later on Windows Server 2016 and later.
- There might be more considerations when you’re working with other SQL Server features and an FCI with a DNN. For more information, see FCI with DNN interoperability.
https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/failover-cluster-instance-distributed-network-name-dnn-configure
Distributed server name as CNO this is perfect for SQL workloads
The big difference is that now the CNO is not an DNN
New-Cluster -Name AzCluster001 -Node ("node001","node002") –StaticAddress 10.80.0.100 -NoStorage -ManagementPointNetworkType Singleton |Set-ClusterQuorum -NodeAndFileShareMajority \\RDSDC01\cluster
The Static IP Address that you appoint to the CNO is not for network communication. The only purpose is to bring the CNO online due to the dependency request. Therefore, you cannot ping that IP, cannot resolve DNS name, and cannot use the CNO for management since its IP is an unusable IP.
Now that we have created the cluster and set the Fileshare Witness we can make the preparations for the file server
Adding the Disks
Before we move on we first add a Azure internal load ballancer. this is needed for the access in the azure subscription.
For creating a loadbalancer we need a loadbalancer and configure the backend pools with a health probe configured to a load balancing rule.
Creating a new loadbalancer is just a quick process but make sure you choose a Internal and a standard one
And place this LB also on the network where the Cluster nodes are.
In the backend pool we added both VM’s that are the cluster noded.
Press save and the cluster nodes are added to the loadbalancer.
In the loadbalancer we need to create a probe that is checking the port and as we are using a file server that is SMB traffic we use the SMB 445 port
Set the interval to 10- seconds and you can keep the rest default – I changed the threshold to 31
last we make a loadballancer rule give this a name and add the backend pool to this.
and the health probe that we just created is also attached.
keep the floating IP on disabled
Now that the Load Balancer is in place we can create the File server role in the Cluster, You can do all this in random order but the powershell script at the end of this blog must run after you configure all of this.
Doing this in the wizard or PowerShell makes the different here, as we need the file server based on a DNS record that’s why we made the Azure LB. We do this with PowerShell
Add-ClusterFileServerRole -Storage "Cluster Disk 1" -Name FS01 -StaticAddress 10.80.0.211
Remember here the IP that is the same IP that is been used in the Azure Load balancer!
But remember, that IP Address is the same unusable IP address as the CNO’s IP. (Cluster IP) You can use it to bring the resource online but that is not a real IP for network communication. If this is a File Server, none of the VMs except the owner node of this VCO can access the File Share. The way Azure networking works is that it will loop the traffic back to the node it was originated from. So it works only on the node where the resource is running.
The Continuous availability is not supported in Azure.
Our next step is creating the File shares. and test the file server. Using the create file share in the Cluster is not working create the file share on the node that holds the Cluster disk. as it may work for you now but as soon as we configured the rest it will not work any more !!
Testing the file share on node 2 and it worked.
as you can see it works BUT you can see I’m logged in into node 2 and test also from node 2. moving the role to node 1 it breaks the file server.
as Azure can’t handle this we need to implement a little fix in PowerShell.
keep in mind that Pinging the CNO or the VCO will not work, as the cluster needs an IP to start but has no function further.
get the cluster properties
So the cluster is running and the fileserver is running but you can only connect on the node where the file share is hosted, That is not how it should work.
We need to utilize the Load Balancer in Azure so this IP Address is able to communicate with other machines in order to achieving the client-server traffic. This can only be don with PowerShell
Load Balancer is an Azure IP resource that can route network traffic to different Azure VMs. The IP can be a public facing VIP, or internal only. Each VM needs have the endpoint(s) so the Load Balancer knows where the traffic should go. In the endpoint, there are two kinds of ports. The first is a Regular port and is used for normal client-server communications.
We used port 445 is for SMB file sharing Another kind of port is a Probe port. The default port number for this is 59999. Probe port’s job is to find out which is the active node that hosts the VCO (Fileserver) in the Cluster. Load Balancer sends the probe pings over TCP port 59999 to every node in the cluster, by default, every 10 seconds. When you configure a role in Cluster on an Azure VM, you need to know out what port(s) the application uses because you will need to add the port(s) to the endpoint. Then, you add the probe port to the same endpoint. After that, you need update the parameter of VCO’s IP address to have that probe port. Finally, Load Balancer will do the similar port forward task and route the traffic to the VM who owns the VCO.
Setting this for our File Cluster and here comes the complicated part, If you have only one nic it is easy the default is cluster network 1
getting the IP resource Name can be found get-clusterresourcename
***here is a different IP 150 as took later the screenshot and rebuild this a couple of times for the blog*
$ClusterNetworkName = “Cluster Network 1”
$IPResourceName = “IP Address 10.80.0.0”
# The IP address that is used in the Load balancer that should be the same than on the Fileserver cluster role.
$ILBIP = “10.80.0.150”
$params = @{"Address"="$ILBIP";
"ProbePort"="59999";
"SubnetMask"="255.255.255.255";
"Network"="$ClusterNetworkName";
"OverrideAddressMatch"=1;
"EnableDhcp"=0}
Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple $params
Running this should set everything to work.
WARNING: The properties were stored, but not all changes will take effect until IP Address 10.80.0.211 is taken offline
and then online again. So I Stopped the Cluster and Started it again
A quick test on my domain controller and test server and it all worked.
As you can see it is rather complicated to run a file cluster in Azure and the question is why ? there are better options for this as netapp files.
https://robertsmit.wordpress.com/2019/08/01/starting-with-azure-netapp-files-is-it-better-than-storage-spaces-direct-in-azure-azure-netapp-storagespaces-s2d-diskspd-wvd-cloud-mvpbuzz-wimvp/
Or using Azure files with Azure AD Support
Step By Step Azure Files share SMB with native AD support
https://robertsmit.wordpress.com/2020/05/11/step-by-step-azure-files-share-smb-with-native-ad-support-and-more-microsoft-azurefiles-smb-snapshotmanagement-azure-cloud-mvpbuzz-wimvp/
Sometimes you need just the cloud mind and step away from what you have. live can get easier and less management.
Thanks for your Support and If you use this let ne know why just a quick post in the comments Thanks!
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
SysAdmin Horror Stories – FREE eBook
Last year’s ebook, SysAdmin Horror Stories Vol1 by Altaro, highlighted some of SysAdmins’ funniest and most horrifying stories. It proved so successful, that Altaro decided to produce a second edition this year: they’ve gathered some more real-life stories to share with you, that are both funny and horrific!
We all know that a SysAdmin’s job is no easy task, and apart from constantly having systems to update, bugs to fix and users to please, SysAdmins encounter all sorts of situations throughout their careers. From tech situations to funny anecdotes, terrible mishaps or incidents with colleagues, this eBook includes real stories of what SysAdmins go through on a daily basis.
It’s very easy to download as no registration is required. Click on Download and it’s yours. It includes more than 20 short stories but this one is my personal favourite .
Download your FREE copy today & Happy Halloween!
Like this:
Like Loading...
