This is second post from the ISCSI administration series ( you can refer the first post here RHEL 6 – ISCSI Administration Series – Configuring ISCSI Server and Client ) . In this post, I will be showing you an hands-on exercise to expand a ISCSI LUN which is already configured from the client and actively in use.
Before going for Actual Task, Just want to show my current configuration both from server side and client side:
ISCSI Server Configuration on RHEL 6
Overall Steps :
- Install the RPM required for ISCSI Target Administration
- Enable the ISCSI Target Services
- Configure the ISCSI target to share the storage
- Attach Luns to the ISCSI Target
- Share the ISCSI Target to specific Client Machines
- Add CHAP user authentication ISCSI target
- Save the configuration to /etc/tgt/targets.conf , so that configuration won’t last after reboot
- Make rules for IPTABLES to accept iscsi client connection on port 3260
This is a following post for my previous SAN migration post Solaris host level SAN migration (with SVM) from Clariion to VMAX. As discussed earlier in my previous post, many organisations started migrating their Server storage from Old legacy SAN devices ( e.g. EMC Clariion ) to new powerful SAN storage ( e.g. EMC Symetrix VMAX) because of the low performance and maintenance costs involved with legacy storage.
Depending on the budget allocated for the Storage Migration projects, some organisations prefer the migration by “direct storage level data replication using expensive migration tools”, while the other companies ( who are with limited budget) prefer to do the migrations by host level data replication. In the later method, the success rate of the migration project directly depends on the skill level and expertise of the unix administrator who is implementing the migration project. I believe this hands-on post will give some idea for the Solaris admins whoever responsible for the Storage migrations. Before going to this post you might want to refer this post for the pre-planning tasks.
LDAP server authentication without encrypted communication is not recommendable for any organization. In this Post, I will be discussing the procedure to configure LDAP server and client to use encrypted authentication and communication. This is third Post in LDAP implementation Series.
Previous posts for your reference
- RHEL 6.3 – LDAP Series – Part 1 : Implementation of LDAP Authentication
- RHEL 6.3 – LDAP Series – Part 2 : Configuration of Certification Authority for LDAP encryption.
Before proceeding to actual configuration, I want to explain few details about the procedures to modify the LDAP configurations.