7 x b200 m2 - Oracle Enterprise Linux RAC 11g w/ RDBMS
2 x b230 m1 - vSphere 5
Site B - Build in progress - remote data centre
7 x b200 m2 - Oracle Enterprise Linux RAC 11g with RDBMS
2 x b230 m1 - vSphere 5 (in progress)
The Site A b230's installed without problem and are fully functional
The Site B b230's however boot from the install iso (the same that was used for Site A) and appear to install correctly to the assigned boot LUN. On reboot however all i get is "Reboot and Select proper boot device or Insert Boot Media in select Boot device and press a key"
The service profiles, aside from the VLAN's assigned to the vnic's and the vhba's, are identical. Both the boot and first datastore are presented during the install but the boot lun, being only 12GB, is what is being install to and it is LUN 0 for the host on the EMC VNX5500.
Both UCS' have the same codebase, 2.0(1m), and were upgraded with the identical progression (1.3 to 1.4(1j) to 1.4(3i) to 2.0(1m)) to ensure they were identical (they weren't installed in parallel due to environmental issues)
FC Upstream for Site A is a Brocade Director 48K
FC Upstream for Site B is a pair of MDS9148's. Zoning is correct and is operational. Cisco Data Centre Network Manager (DCNM) has been deployed and is monitoring both the MDS' and the Site B UCS.
Has anyone seen this behaviour before? It's got me baffled.
If you're zoning and everything else looks good, chances are it is one of the following:
1) Depending on if the array is active/active or active/passive, it is also important to verify which storage processor currently owns the LUN and ensure that the vHBA communication is hitting the appropriate storage processor
2) Also ensure that you have correctly configured the order of your Boot from SAN targets (primary vHBA - primary target, primary vHBA - secondary target, secondary vHBA - primary target, secondary vHBA - secondary target). The order in which it attempts to boot from the LUN is important.
Have a look over these two items and ensure that everything is correct.
Checked the whole storage thing, we had wound it down to have a single path (which had a single initiator and single storage target) in it, but had no effect. Basically we ran through all the lessons learnt while deploying Oracle Enterprise Linux on UCS (like order of the Boot targets) to no avail.
This led me to roll the firmware of the adapter back to 1.4.3i, which seemed to work but it's a step back for us. Upon looking a bit deeper into the problem I saw that 2.0.1m has got a deferral notice, and most the bugs were against ESX and B230's. So I've upgraded to 2.0.1t on the FI and UCSM, applied 2.0.1t firmware to the FC adapter and it works beautifully.
As we are trying to keep both UCS' at the same codebase (as they are designed for BCP not DR), Site A will now get an upgrade (and with any luck before christmas).
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...