Update after you provided a diagram:
You already have a circle there at the bottom half of the diagram. It looks like the ACEs don't bridge, so if you don't have a problem there you shouldn't have a problem connecting the two top ones.
It's a bit hard to talk about the diagram if you don't name the devices, but let's say I name them left to right, top to bottom. You have a circle ACE1-SW3-ACE2-SW4-ACE1..., obviously there's no problem there (right?). I'm guessing you configured the ACEs so they don't bridge any traffic at all, and therefore no loop.
Why not connect ACE1 to SW2 and ACE2 to SW1? Then you have the same setup as the bottom part.
If you have a different VLAN in the top and bottom parts (not the same layer2 segment) then you can't have a spanning tree loop between them.
It would be clearer if you provided (obfuscated if you like, but make sure we can tell network A from B. Such as 10.123.0.0/24 and 10.123.1.0/24) IP networks on the map, and perhaps VLANs (if you use them).
Update after naming the switches:
If the ACE do routing, and therefore are the next-hop for the servers on 10.0.0.0/24 etc.., and don't do bridging (in the ACEs), then connecting the way I said above is safe.
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
Presumably your 4 Linux servers have at least two nics? Do they actually need the combined bandwidth of both nics to handle their normal load? If not then some of the bonding modes provide for redundancy without using etherchannel.
Anway, see the bonding document it provides lots of several example HA situations depending on what you need, and what your network hardware is capable of.
Excerpt from bonding.txt
11.2 High Availability in a Multiple Switch Topology ---------------------------------------------------- ... Below is a sample network, configured to maximize the availability of the network: | | |port3 port3| +-----+----+ +-----+----+ | |port2 ISL port2| | | switch A +--------------------------+ switch B | | | | | +-----+----+ +-----++---+ |port1 port1| | +-------+ | +-------------+ host1 +---------------+ eth0 +-------+ eth1 In this configuration, there is a link between the two switches (ISL, or inter switch link), and multiple ports connecting to the outside world ("port3" on each switch). There is no technical reason that this could not be extended to a third switch. 11.2.1 HA Bonding Mode Selection for Multiple Switch Topology ------------------------------------------------------------- In a topology such as the example above, the active-backup and broadcast modes are the only useful bonding modes when optimizing for availability; the other modes require all links to terminate on the same peer for them to behave rationally. active-backup: This is generally the preferred mode, particularly if the switches have an ISL and play together well. If the network configuration is such that one switch is specifically a backup switch (e.g., has lower capacity, higher cost, etc), then the primary option can be used to insure that the preferred link is always used when it is available. broadcast: This mode is really a special purpose mode, and is suitable only for very specific needs. For example, if the two switches are not connected (no ISL), and the networks beyond them are totally independent. In this case, if it is necessary for some specific one-way traffic to reach both independent networks, then the broadcast mode may be suitable.