Until recently, my Server.app Mac Pro has been solely on my XSan network, and my 1GbE ports have been turned off. My second and third Mac Pro computers are on my corporate network with the 1GbE ports, but the 10GbE ports are set specifically for the XSan network. I had trouble with the authconfig file on each of the other Macs, but once I had them set, they were good. I then setup my users, and used your suggestions to configure the clients. With the 65TB target set for video, and the 1TB target set for metadata and journaling, XSan picked it up right away and started working with it. Once I connected the iSCSI target, Finder wanted to format it, but I ignored it and had Server.app format it in the XSan pane. The main Server.app is running on one of the Mac Pros. I tried a few others, but GlobalSan has proven to be very reliable. As long as the aggregation is set on both the computer and the switch, it connects easily.Įach of the Mac Pros has GlobalSan installed for the iSCSI initiator. Each Mac Pro has a Promise Sanlink 2 attached, which allows Thunderbolt 2 to dual 10GbE and supports link aggregation. I have three of the new black Mac Pros running Yosemite. The switch I’m using is the new Netgear XS712T, which supports link aggregation. The server also has two 10GbE ports that I bonded. Then, I created two iSCSI target images, one at 65TB, and one at 1TB. I have three RAID 5 sets of 14 drives and one hot spare each, and then I put the three RAID 5 sets into a RAID 0 configuration. I’m using a 45Drives Storinator running Centos 7 as my server. I haven’t done any write-up on it, but it was pretty simple. I know iSCSI isn’t the best way in the world to connect, but until this week, it worked just fine. I’m thinking I may have to cut off any other networks, and maybe use the Centos server as a proxy to the rest of the world. I have it set up as a primary OD controller for my 10GbE network, and DNS primary as well. Also, none of my clients can mount the volume, which I assume is because the MDC doesn’t see the volume in Server.app. When I try to create a volume, it gives me a “cannot create nil from object” error. Now, my Xsan volume automatically mounts on my primary MDC, but Xsan in the Server.app shows no volumes. Not sure if that had anything to do with it, but when I came back, the whole SAN was destroyed and my users and groups were gone. I went on vacation for a week, and one user decided he would leave himself logged in for the entire week. Everyone was able to log in, files were being transferred and checked out with no issues, and I had data transfer speeds nearing 700MB/s. I was able to get it all set up so that the user home folders were based on the server, and I had a backup on the primary MDC. My connection is iSCSI over dual 10GbE to a 45drives server running Centos 7. I had everything running just fine two weeks ago. Use MDM or manually deliver the file to your clients. If an Xsan 3 (10.9 client) is part of Xsan 4 (10.10) then it may work but commands and configs will not come across (unmount / mount the volume, the volume is destroyed stop looking for it, etc).Īnd now for some screenshots of the actual setup. More testing is needed, but strictly speaking Xsan 4 is not going to work with Xsan 3 and vice versa. I have not tested Xsan 4 with StorNext but I expect there is compatibility, as usual. To configure the clients you export a config profile and install it on the clients, or alternatively you can enrol the Xsan controller in MDM (Profile Manager, for example) and push out the config to the clients. If you have OD then join your Xsan controllers to it as replicas or else they will create a new OD master on the first Xsan controller and a replica on the second. If there is no OD master set up then it will create one (same with DNS). Also, it depends on Open Directory (and DNS, of course). I’ve done some basic testing with Xsan 4 and it does away with the Xsan Admin app, all setup is done in the Server.app. There may be a hack to get incompatible versions working together but that’s left to imaginative tinkerers and not useful for production where deadlines are involved. You can NOT have Xsan 3 (10.9) clients on a 10.10 Xsan, and I don’t think that 10.10 (Xsan 4) clients will work on a Xsan 3 based SAN. What you need to know is, if you upgrade your Mac to 10.10 then it is officially incompatible with Xsan 3. Install OS X 10.10 on a test system first. If your systems are in production then please leave them as is. But don’t get too excited and upgrade your OS without some planning (and backups). The big news for me is the built-in version of Xsan is v.4. Apple released Yosemite (OS X 10.10) today.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |