|
|
|
Question : Problem: WTF's up with my iSCSI network config ???
|
|
Experts:
I just purchased an EMC AX4-5i dual-SP SAN appliance; two racks, one for SAS drives and the other with SATA drives. I'm just setting up the appliance and I'm stuck, hoping you all can help me figure something out.
If you look at the attached file you'll notice my vanilla setup: 1 server with 3 NICs connected to a pair of GigE switches configured in a meshed network connecting a pair of SP units, each with two iSCSI ports of their own.
The problem I'm having is that on the server i can only ping one of two switches and only two of four iSCSI ports
C:\Program Files\Support Tools>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : galapagos
Primary Dns Suffix . . . . . . . : xxx.local
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : Yes
DNS Suffix Search List. . . . . . : xxx.local
Ethernet adapter 192.168.253.98:
Connection-specific DNS Suffix . : xxx.local
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Server Adapter
Physical Address. . . . . . . . . : 00-04-23-AB-6A-0B
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.253.98
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter 192.168.253.99:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Server Adapter #2
Physical Address. . . . . . . . . : 00-04-23-AB-6A-0C
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.253.99
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter 192.168.10.25:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : HP NC3163 Fast Ethernet NIC
Physical Address. . . . . . . . . : 00-50-8B-EB-15-1C
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.10.25
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.10.1
DNS Servers . . . . . . . . . . . : 192.168.10.13
192.168.10.25
Primary WINS Server . . . . . . . : 192.168.10.13
Secondary WINS Server . . . . . . : 192.168.10.25
C:\Program Files\Support Tools>ping 192.168.253.199
Pinging 192.168.253.199 with 32 bytes of data:
Reply from 192.168.253.199: bytes=32 time=3ms TTL=64
Reply from 192.168.253.199: bytes=32 time=2ms TTL=64
Reply from 192.168.253.199: bytes=32 time=1ms TTL=64
Reply from 192.168.253.199: bytes=32 time=2ms TTL=64
Ping statistics for 192.168.253.199:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3ms, Average = 2ms
C:\Program Files\Support Tools>ping 192.168.253.198
Pinging 192.168.253.198 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.253.198:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Program Files\Support Tools>ping 192.168.253.200
Pinging 192.168.253.200 with 32 bytes of data:
Reply from 192.168.253.200: bytes=32 time<1ms TTL=64
Reply from 192.168.253.200: bytes=32 time<1ms TTL=64
Reply from 192.168.253.200: bytes=32 time<1ms TTL=64
Reply from 192.168.253.200: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.253.200:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Program Files\Support Tools>ping 192.168.253.201
Pinging 192.168.253.201 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.253.201:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Program Files\Support Tools>ping 192.168.253.202
Pinging 192.168.253.202 with 32 bytes of data:
Reply from 192.168.253.202: bytes=32 time=1ms TTL=64
Reply from 192.168.253.202: bytes=32 time<1ms TTL=64
Reply from 192.168.253.202: bytes=32 time<1ms TTL=64
Reply from 192.168.253.202: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.253.202:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
C:\Program Files\Support Tools>ping 192.168.253.203
Pinging 192.168.253.203 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.253.203:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Program Files\Support Tools>
So before I go any further and start configuring iSCSI initiators or LUNs, etc...I wanted to clear up this networking mystery
Thanks,
juckyt
|
Answer : Problem: WTF's up with my iSCSI network config ???
|
|
Don't know it this will help, but I'll describe what I do for our WAN:
Firstly we don't need to back up huge amounts of data, but we do need to collect from a lot of machines, some of them on a slow link!
Our main app server is Linux based - on that I run an open-source app called bacula. (If you need to run this on Windows, it can be run using Cygwin in a CMD window)
It's main features are:
All backup strategies, schedules, storage etc are managed on the backup server. Other than the initial client install, no work needs to be done on the clients, so it doesn't matter if they are remote or hard to get to). All communications over the network are password protected and data can be compressed before transmission to improve performance over slow links.
Each client machine runs a small app (windows/linux/mac OS etc all available) that uses TCP-IP to communicate with the backup server. Because the small client app runs in the user space on the client, it has access to all files that the user does, even if their machine has no shares.
For each machine you want to backup, you have to set up a job description, a fileset, a client description and associate the backup with a schedule and storage device (which can be tape. disk or whatever). The system gives full control over timeouts (for machines that are not always on) and will queue jobs of equal priority, again with control over when they are allowed to execute etc) It takes some getting your head around, but once you've done that the whole system is very effective. You can also tell it to email you with details of all backups, errors etc. A console app allows you to interact with the backup service and manually control jobs, storage, do restores etc from any machine on the network.
Restores can be to the last backup, or to any date (in the backup set) you desire. So in other words you could restore your files to how they were, say, five days ago. Restores are always made (unless you specifically over-ride this) to a separate directory on the client machine so that nothing gets accidentally overwritten, and with all user permissions etc preserved.
This backup server talks to a small (by coincidence Linux controlled) NAS unit that has two removable 250GB drives connected. A number of backups are scheduled throughout the day for user machines, and overnight for local and remote servers. Early every morning the NAS unit itself clones drive 1 to drive 2. We keep four 250GB drives in the backup set, and rotate them one a month. Our backup schedule is designed to cycle every three months, hence at any one time we have snapshots for approx one year's data. One drive is kept in the fire-safe, another off-site.
If you wanted to create permanent archives then you would need a slightly different set-up that didn't re-use the backup storage over time but always asked for new tapes/disks etc.
For the small amount of live data that changes rapidly, we make hourly backups across the network to other machines, and to DVD-RAM. The DVD-RAM disks are changed weekly.
So, at any one time, we have a year's data available for all client machines, and backups current to within an hour for the most critical data. The worst case scenario, if the building burnt down just before we went home in the evening, is that we would lose one months less critical data from the user's machines, and one day's worth of critical data, but for our operation that is an acceptable risk. The 'average' risk would be to lose half a day's critical data and a couple of weeks non-critical.
If you want further details, let me know...
Mike
|
|
|
|
|
