Absolutely you can. You're looking for 802.1q tagging, which is the underpinning of multiple VLANs on a switch.
Configure your server-facing ports like this...
interface GigabitEthernet0/1
! tell the switch to encapsulate frames with dot1q on this trunk port
switchport trunk encapsulation dot1q
! make this a trunk port unconditionally
switchport mode trunk
! allow VLANs 220, 221, and 223 to be sent on this port
switchport trunk allowed vlan 220,221,223
! send vlan 221 frames untagged
! you could omit this command, but you'll need to move your eth0 config to a subinterface as well
switchport trunk native vlan 221
! this is an end-device, and doesn't need to be treated like a switch for spanning-tree
spanning-tree portfast trunk
! remove the (ignored) access vlan setting, as this is now a trunk
no switchport access vlan
On your Ubuntu server you'll need to configure the subinterfaces to be associated to each appropriate VLAN. This can be done manually like this ...
# create a new subinterface tied to dot1q vlan 221
ip link add link eth0 name eth0.221 type vlan id 221
# change the MTU to allow for the inserted dot1q tag (4 bytes)
ifconfig eth0 mtu 1504
# bring the new interface up
ifconfig eth0.221 up
Now you can associate the correct IP address to new interface eth0.221, along with the appropriate default gateway and subnet mask.
If this doesn't work for you, please include a pastebin link to your switch config as well as the output of "ip -d link show" on your Ubuntu server.
Hope this helps!
Based on your edits and comments, I don't think that this is spanning-tree delay that you're seeing. The downtime that you're describing (2 minutes) is really too long to be explained by STP, and I kind of doubt that the Linux servers are running STP with the switches. You also basically are doing single-switch spanning-tree, as a switch stack is considered one logical switch.
There are some STP tweaks that are probably a good idea in your situation, though. First of all, you can re-enable Spanning-Tree on your VLANs -- no reason to have it turned off. Mode rapid-pvst is a good idea unless you're trying to run spanning-tree with the Linux boxes. You can also tell the switch that the trunks towards your Linux devices (Gi1/0/2) are not switches.
spanning-tree vlan 1,100
interface GigabitEthernet1/0/2
spanning-tree portfast trunk
That leaves the other redundancy features you've got here, which are the switch stack itself, HSRP, and anything on the Astaros.
My bet is on the failure recovery mechanism on the Astaros. Since you mentioned that one is "master", that implies that only one is active at any one time. What kind of timers are setup on the Astaros devices for failover? Do you have any logs that indicate how long it takes the standby device to go active after the switch fails?
Spanning-tree doesn't seem right because of the fact that all the STP is being done on one switch, and because of the downtime. The switch stack (at least on 3750 stacks) failover should be faster than that too, although you might hookup a console to the secondary switch to see if its taking a long time to take over as master. HSRP (assuming its running at the provider and not on your switches) will also fail a good bit faster than that, and shouldn't be affecting you.
TL;DR -- I think it's the failover timers on your Linux boxes that are causing the delay. Second place goes to the switch stack taking a long time to have the secondary switch take over as master.
Best Answer
The management VLAN, for all intents and purposes, is a logical construct and is specific to your configuration. Your management VLAN doesn't have any commonality with my management VLAN other than the fact that they both have an SVI with an ip address assigned to it. You can create a management VLAN from any VLAN you like because at the end of the day the management VLAN is nothing more than an SVI that you assign an ip address to for the purpose of managing the switch.
If you assign a port to the management VLAN then you cannot assign that port to another VLAN as a port may be a member of only one VLAN, but this doesn't have anything to do with whether or not you're using that VLAN as a management VLAN. If you connect a host to a port that is a member of your management VLAN than that host will only communicate with other hosts in the same VLAN, but this has nothing to do with whether you consider this VLAN a management VLAN or not. The fact that you're using this VLAN as your management VLAN is irrelevant to the switch. The "management" VLAN is a construct of your management needs. The switch doesn't know one VLAN from another in terms of what the VLAN is used for.
The native VLAN isn't affected by creating a management VLAN and the native VLAN is only relevant to trunk ports (AFAIK). Traffic on the native VLAN isn't tagged and as such will transit the trunk link untagged and will be delivered to switch ports that have membership in the native (default-untagged) VLAN. Again, the native/default VLAN isn't relevant to what VLAN you use as your management VLAN. The management VLAN is nothing more than an SVI with an ip address that you use to manage the switch.