Menu

howto get access ilo’s “Direct terminal access” via Serial Console

hi. so you’ve got some HP DL’s (like dl380 … ) servers and you’ve setup ilo to get access to terminal.

after you enabled ssh remote access (it is enabled by default) for ilo run this :

# ssh <user>@<ilo-ip-address>

</>hpiLO-> TextCons

maybe your terminal freezzzz . so in os you should add this line in /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT=”vga=normal nomodeset 3″

# update-grub

# reboot

then try again.

BTW : i’ve got some nice tutorial to enable serial console for virtual machines here .

linux-dash: Monitors “Linux Performance” Remotely Using Web Browser

at First, go to demo 😀 : http://afaq.dreamhosters.com/linux-dash/

pre-requirement: 

  • A Linux server with Apache/Nginx installed.
  • A PHP and php-json extension installed.
  • A unzip utility installed on server.
  • Optionally, you need htpasswd installed, to password protect the statistics page on your server.

install packages:

# apt-get install apache2 apache2-utils

# apt-get install php5 curl php5-curl php5-json

 

# git clone https://github.com/afaqurk/linux-dash.git 

finally : http://localhost/linux-dash

 

reference : https://github.com/afaqurk/linux-dash

Setting Grub 2 Password

I don’t no why I can’t add it before… ;because it’s so easy

  1. First of all, we must define user and password for it.
    • cp /etc/grub.d{,.bac}
      cd /etc/grub.d
      vim 00_header

      cat << EOF

      set superusers=”simon”

      password simon 123456

      password othuser 1234

      EOF

      • add these lines to end of file

  2. Protecting:
    1. All linux kernels (just linux):
      vim 10_linux

      find this:

      printf “menuentry ‘${title}’ ….

      and change it to:

      printf “menuentry –users simon othuser ‘${title}’ ….

    2. All menu entries:

      sed -i -e ‘/^menuentry /s/ {/ –users simon othuser {/’ 10_linux 20_linux_xen 30_os-prober 40_custom 41_custom

  3. Finish by these commands:

    update-grub

    reboot # have fun😉

some notes about IO schedulers

1. To choose IO schedulers at boot time, use the argument ‘elevator=deadline’.
‘noop’ and ‘cfq’ (the default) are also available. IO schedulers are assigned
globally at boot time only presently.

2.  The list of defined schedulers can be found by simply doing :
cat /sys/block/<device>/queue/scheduler

3. To set a specific scheduler, simply do this:
echo SCHEDNAME > /sys/block/DEV/queue/scheduler
where SCHEDNAME is the name of a defined IO scheduler, and DEV is the
device name (hda, hdb, sga, or whatever you happen to have).

4. to update scheduler via grub:
Edit /etc/default/grub, such as gksudo gedit /etc/default/grub, here you need to add elevator=noop .

Change GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash” to GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash elevator=noop”.

Then run sudo update-grub2 and restart.

sample:
# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo deadline > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

which scheduler ?
this is what i’ve found by searching so far but not tested:
1. Noop:   if your system is CPU-bound and the storage is fast
2. cfq : is good for most of workloads. even databases.
3. Deadline :  recommended for databases  by linux kernel documentation

basic concepts:

Linus Elevator :
such as the one taken by the 2.4 Linux kernel’s I/O scheduler, the Linus Elevator—is to simply stop insertion-sorting if there is a sufficiently old request in the queue. This trades overall performance for per-request fairness and, in the case of reads, improves latency. The problem is that this heuristic is a bit too simplistic. Recognizing this, the 2.6 Linux kernel witnessed the demise of the Linus Elevator, and unveiled several new I/O schedulers in its place.

Deadline I/O Scheduler:
was introduced to solve the problems with the 2.4 I/O scheduler, and traditional elevator algorithms in general. The Linus Elevator maintains a sorted list of pending I/O requests. The I/O request at the head of the queue is the next one to be serviced. The Deadline I/O Scheduler keeps this queue, but kicks things up a notch by introducing two additional queues: the read FIFO queue, and the write FIFO queue. The items in each of these queues are sorted by submission time (effectively, the first in is the first out). The read FIFO queue, as its name suggests, contains only read requests. The write FIFO queue, likewise, contains only write requests. Each request in the FIFO queues is assigned an expiration value. The read FIFO queue has an expiration time of 500 milliseconds. The write FIFO queue has an expiration time of five seconds.
When a new I/O request is submitted, it is insertion-sorted into the standard queue, and placed at the tail of its respective (read or write) FIFO queue. Normally, the hard drive is sent I/O requests from the head of the standard sorted queue. This maximizes global throughput by minimizing seeks, as the normal queue is sorted by block number (as with the Linus Elevator).
When the item at the head of one of the FIFO queues grows older than the expiration value associated with its queue, however, the I/O scheduler stops dispatching I/O requests from the standard queue, and begins servicing requests from that queue—the request at the head of the FIFO queue is serviced, plus a couple of extras for good measure. The I/O scheduler needs to check and handle only the requests at the head of the queue, as those are the oldest requests.
In this manner, the Deadline I/O Scheduler can enforce a soft deadline on I/O requests. Although it makes no promise that an I/O request will be serviced before its expiration time, the I/O scheduler generally services requests near their expiration times. Thus, the Deadline I/O Scheduler continues to provide good global throughput without starving any one request for an unacceptably long time. Because read requests are given shorter expiration times, the writes-starving-reads problem is minimized.

Noop
The Noop I/O scheduler implements a simple first-in first-out (FIFO) scheduling algorithm. Merging of requests happens at the generic block layer, but is a simple last-hit cache. If a system is CPU-bound and the storage is fast, this can be the best I/O scheduler to use.

ref:

http://my.safaribooksonline.com/book/operating-systems-and-server-administration/linux/0596009585/advanced-file-i-o/i_solidus_o_schedulers_and_i_solidus_o

http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaat%2Fliaatbpscheduleroverview.htm

Follow

Get every new post delivered to your Inbox.