Krystalmods.com

<rant>

I purchased an LSI MegaRaid 9265-8i controller a while ago in favor of Areca 1880 series controllers. This was to replace the old Areca ARC-1230 that started to show problems. I've been happy with the performance with the LSI controller, but as with any product, there's more than just pure performance.

First thing I hate: LSI's WebBIOS is neither intuitive, nor well designed. It's ancient at best and disorganized. I've seen the same disorganized management in a very old Intel (LSI) controller that could only output 20MB/s RAID5. Areca in comparison has a simple menu BIOS that doesn't try to be more, it just works and there's nearly no need to second guess your self.

Second thing I hate: MegaCLI is possibly the worst writtle CLI in the history of computing! Do I even have to say anything? Just try this search. Everything is cryptic yet there's a lack of documentation or easy access to help. Areca goes for a CLI system that provides more detailed help for each command and the commands actually make sense!

Third thing I hate: Expansion is only possible when adding additional drives. It is not possible when replacing drives with larger drives. Well, that's not true, it is possible, but you have to run a DOS program, send the output to LSI after creating a support case, then LSI will tell you how to do it. Here's exactly how LSI describes it. On Areca, I just say expand and the size and wait while the server go about its business, no questions asked!

Verdict: If you like high IOPS and don't mind horrible management from a very long running big player in the RAID controller industry, get an LSI. If you want to make your life easier, please, please just get an Areca controller! If LSI spent less time making useless GUIs with Java that doesn't do much good or spend so much time deciding how to abreviate a command, maybe they'd actually be able to make a product that doesn't increase management overhead by 1000%.

</rant>

Edit: The following has only been tested successfully with Intel NICs flashed with iSCSI boot ROM. iBFT in Broadcom NICs are currently not compatible with XenServer as it may require kernel >=3.0.

Many have found them selves in my position where they'd like to use XenServer and would like to install it directly onto iSCSI. Microsoft has made it easy to boot (personal experience) from iSCSI in Windows 7 and 2008 using NICs supporting iSCSI boot. The same goes with VMware ESX since version 4.1 (not personal experience). Unfortunately, as many have known, XenServer does not officially support this.

There has been only one writeup that details how iSCSI boot is possible in XenServer here. However, in XenServer 6.0, this resulted in failure to create initrd. Once initrd was fixed manually, the server boots properly but since the installation failed during the final steps, some configuration is missing.

Anyway, there's really no need to get into details of my debugging efforts. Reason being that I've found what appears to be fully functional iSCSI boot feature in the installation scripts!!! Use the following if you have iSCSI boot capable NIC (one that has iBFT):

• Boot the installation disk and enter "shell" at the boot prompt
• Once you are at the shell prompt, enter "/opt/xensource/installer/init --use_ibft --mpath"

Those two options are important as they will ensure that the network kernel module and settings as well as the iSCSI settings are set up in the initrd. This will also reserve the NIC that has iSCSI boot configured, for iSCSI. I've found that it can still be used for other  purposes eventhough during installation, they will be removed from the list of available NICs for management interface.

So there you go, XenServer 6 (and maybe others) supports iSCSI boot...with no drama......unofficially!

I've played around with GlusterFS a few times now. First it was the distribution which they eventually stopped making. Then it was the RedHat RPM packages (also available for debian/ubuntu) which worked out pretty well. In the near future, I'll be testing Openstack which can use GlusterFS for storage of virtual machine nodes.

I always had some minor issues compiling it for Opensuse or SLES. Recently, I realized that GlusterFS has been added to Opensuse's official distribution (on the DVD and in the defualt repository). Well, needless to say that I jumped on the opportunity. As of a couple days ago, this site runs on Opensuse 12.1, Nginx, and GlusterFS. GlusterFS is only used for website data for the time being but I'm looking into testing it out for other purposes such as Email server.

Everything went as expected without any issues. To get it going with a basic network mirror (assuming DNS or hosts file configured and /data is where the data partition is mounted):

gluster1# zypper in glusterfs
gluster1# chkconfig glusterd on
gluster2# zypper in glusterfs
gluster2# chkconfig glusterd on
gluster1# gluster
gluster> peer probe gluster2
gluster> volume create replica 2 gluster1:/data gluster2:/data

Now to mount the gluster volume on the client servers. Install glusterfs there with zypper too. Add the following to /etc/fstab file.

gluster1:/data  /data    glusterfs       defaults,_netdev        0 0

Notice the option "_netdev". This will ensure the network is up and running before mounting the volume. To mount it before system is rebooted:

mount /data

Notice also that we are mounting using gluster1 DNS entry (this can be IP address). If gluster1 is offline, this will fail. However, you can quickly change it to gluster2 and mount. During a failure of one of the gluster nodes, this no longer affects the client as glusterfs client connects to all nodes available during mount and will ensure availability during failures.

So I'm sitting on the datacenter floor once again. This time, it's thanks to HP's iSCSI storage array's inability to comprehend certain characters in passwords. It could be the @ symbol or the length of password but this is not the first time I've lost complete access to HP equipment (iLO and MSA arrays) after a password change. This also makes me think if the password field can be exploited on HP MSA and iLO devices.

Anyway, G3 array has a login prompt for the local console access while G2 arrays didn't. This meant that this password recovery document is useless on G3 arrays. Durring searching online, I was reminded of the old hidden account "admin" with password "!admin" in the G3 arrays. Gave it a try and what do you know, it works. Best part, if you didn't know about it, chances are, you won't find out because it's not listed as one of the users.

I'll have to change this password, but that's after I find a suitable password for the "manage" user that won't lock me out!

Good job HP! (For those at HP, that's sarcasm.)

After hearing about the possibility of removing Apache completely, I took a look and found the following link:

http://www.howtoforge.com/installing-nginx-with-php5-and-php-fpm-and-mysql-support-on-opensuse-12.1

Following these instructions was fairly simple. I skipped mysql server setup in the instructions as I prefer to separate my database servers from the application layer. There was one issue though. The following warning started appearing on php pages. For b2evolution version 3.x, it showed up so many times that the page was impossible to read.

PHP Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Newyork' for 'CEST/2.0/DST' instead in /usr/share/nginx/html/info.php on line 2

Now then, some of the guides for Centos mentioned the same issue. It suggested modifying php.ini. However, I couldn't really find one for php-fpm. The suggested change to php.ini does not work in php-fpm.conf file. To resolve this, add the following to /etc/php5/fpm/php-fpm.conf:

php_admin_value[date.timezone] = 'America/New_York'

This resolves the problem.

As for b2evolution's system check, a couple settings need to change to ensure security. Add the following to /etc/php5/fpm/php-fpm.conf:

php_admin_flag[magic_quotes_gpc] = off

We also need "allow_url_fopen", however, the override in php-fpm.conf doesn't work. To get around this, we have the option of adding the following to /etc/nginx/nginx.conf:

fastcgi_param       PHP_VALUE       "allow_url_fopen=off";

One final issue exist. B2evolution has been configured to use "extra-path" instead of "param" for URLs like this: http://www.krystalmods.com/index.php/2006/blah

This is due to nginx looking at it as a directory rather than php script now. It goes to find the file but cannot find it. To resolve this issue, we switch to "param" so it says: http://www.krystalmods.com/index.php?title=blah&more=1

Although this solves the issue, consider if your website has been live for a while with "extra-path" set up. By changing to "param", the URL now changes which means it will take some time for search engines to crawl through. This also renders referring links from other websites useless. I don't have time to look into a solution now. Hopefully I'll find a solution for this in the future.

Results

If you are looking at this page right now, then the results are right here. Memory usage is low to start, however, it increases as php-fpm get some requests. Its memory footprint increases for each child process, possibly for caching. Memory usage while serving requests is equivalent to apache sitting idle unless if you decide to have a lot of php-fpm children running. Nginx it self uses very little memory. The best part is the reduced CPU usage. If I find some time, and remember, I'll test on an isolated system for both scenarios to get some performance numbers for comparison.