Archive for the ‘SAN’ Category

Testing NetApp’s SyncMirror whole plex failure (on simulator)

Thursday, May 20th, 2010

Together with Lukasz Borek we’ve tested the SyncMirror reliability under some stress…. In short basic NetApp deployment just uses RAID-DP (Double Parity, so you are might 2 disks fail before you loose data). If your data is critical, they you can actually configure SyncMirror which just mirrors aggregate (on top of which are volumes) to two plexes, each consisting of RAID group(s). This behaves like RAID-1 which is using two RAID-DP (you have double ammount of disks protecting you). Simple demonstration (just before this we’ve removed all spare disks for demonstration purposes)

So we have our aggregate aggr_mirr:

filerA> aggr status -r
Aggregate aggr_mirr (online, raid_dp, mirrored) (block checksums)
  Plex /aggr_mirr/plex0 (online, normal, active, pool0)
    RAID group /aggr_mirr/plex0/rg0 (normal)

      RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------  ------------- ---- ---- ---- ----- --------------    --------------
      dparity   v5.19   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
      parity    v5.20   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
      data      v5.24   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448

  Plex /aggr_mirr/plex1 (online, normal, active, pool0)
    RAID group /aggr_mirr/plex1/rg0 (normal)

      RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------  ------------- ---- ---- ---- ----- --------------    --------------
      dparity   v5.25   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
      parity    v5.26   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
      data      v5.27   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448

[..]

Pool1 spare disks (empty)

Pool0 spare disks (empty)

Broken disks

RAID Disk       Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
---------       ------  ------------- ---- ---- ---- ----- --------------    --------------
admin removed   v4.16   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.17   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.20   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.21   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.22   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.24   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.25   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.26   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.27   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.28   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.29   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v4.32   v4    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v5.28   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v5.29   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
admin removed   v5.32   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448

We want to fail all of the disks (5.19, 5.20, 5.24) that are part of /aggr_mirr/plex0/rg0 (that simulates loosing whole plex, we wanted to test that aggr_mirr is going to be able survive crash of one of the plexes):

filerA> disk fail v5.19
*** You are about to prefail the following file system disk, ***
*** which will eventually result in it being failed ***
  Disk /aggr_mirr/plex0/rg0/v5.19

      RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------  ------------- ---- ---- ---- ----- --------------    --------------
      dparity   v5.19   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
***
Really prefail disk v5.19?  y

WARNING! There is no spare disk available to which to copy.
Are you sure you want to continue with disk fail (y/n)? y
disk fail: The following disk was prefailed: v5.19
Disk v5.19 has been prefailed.  Its contents will be copied to a
replacement disk, and the prefailed disk will be failed out.
filerA>
Tue Apr 27 18:03:52 GMT [raid.rg.diskcopy.cant.start:warning]: /aggr_mirr/plex0/rg0: unable to start disk copy for v5.19: No block checksum disk of required type and size is available, targeting Pool0
filerA>
filerA> disk fail v5.20
*** You are about to prefail the following file system disk, ***
*** which will eventually result in it being failed ***
  Disk /aggr_mirr/plex0/rg0/v5.20

      RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------  ------------- ---- ---- ---- ----- --------------    --------------
      parity    v5.20   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
***
Really prefail disk v5.20? yes

WARNING! There is no spare disk available to which to copy.
Are you sure you want to continue with disk fail (y/n)? y
disk fail: The following disk was prefailed: v5.20
Disk v5.20 has been prefailed.  Its contents will be copied to a
replacement disk, and the prefailed disk will be failed out.
filerA>
filerA>
filerA> disk fail v5.24
*** You are about to prefail the following file system disk, ***
*** which will eventually result in it being failed ***
  Disk /aggr_mirr/plex0/rg0/v5.24

      RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------  ------------- ---- ---- ---- ----- --------------    --------------
      data      v5.24   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
***
Really prefail disk v5.24? y

WARNING! There is no spare disk available to which to copy.
Are you sure you want to continue with disk fail (y/n)? y
disk fail: The following disk was prefailed: v5.24
Disk v5.24 has been prefailed.  Its contents will be copied to a
replacement disk, and the prefailed disk will be failed out.
filerA>
filerA> disk simpull  v5.19
Tue Apr 27 18:06:08 GMT [raid.config.filesystem.disk.missing:info]: File system Disk /aggr_mirr/plex0/rg0/v5.19 Shelf ? Bay ? [NETAPP   VD-1000MB-FZ-520 0042] S/N [16402503] is missing.
filerA>
Tue Apr 27 18:06:08 GMT [raid.rg.recons.missing:notice]: RAID group /aggr_mirr/plex0/rg0 is missing 1 disk(s).
Tue Apr 27 18:06:08 GMT [raid.rg.recons.cantStart:warning]: The reconstruction cannot start in RAID group /aggr_mirr/plex0/rg0: No block checksum disk of required type and size is available, targeting Pool1
filerA>
filerA> disk simpull  v5.20
Tue Apr 27 18:06:16 GMT [raid.disk.missing:info]: Disk /aggr_mirr/plex0/rg0/v5.20 Shelf ? Bay ? [NETAPP   VD-1000MB-FZ-520 0042] S/N [16402504] is missing from the system
Tue Apr 27 18:06:16 GMT [raid.config.filesystem.disk.missing:info]: File system Disk /aggr_mirr/plex0/rg0/v5.20 Shelf ? Bay ? [NETAPP   VD-1000MB-FZ-520 0042] S/N [16402504] is missing.
filerA>
Tue Apr 27 18:06:17 GMT [raid.rg.recons.missing:notice]: RAID group /aggr_mirr/plex0/rg0 is missing 2 disk(s).
Tue Apr 27 18:06:17 GMT [raid.rg.recons.cantStart:warning]: The reconstruction cannot start in RAID group /aggr_mirr/plex0/rg0: No block checksum disk of required type and size is available, targeting Pool1
filerA>
filerA> disk simpull  v5.24
Tue Apr 27 18:06:20 GMT [raid.config.filesystem.disk.missing:info]: File system Disk /aggr_mirr/plex0/rg0/v5.24 Shelf ? Bay ? [NETAPP   VD-1000MB-FZ-520 0042] S/N [16402507] is missing.
Tue Apr 27 18:06:20 GMT [raid.vol.mirror.degraded:error]: Aggregate aggr_mirr is mirrored and one plex has failed. It is no longer protected by mirroring.

So we’ve destroyed whole plex! Great success! ;) In real world this would be more like whole shelf failure. NetApp controller of course tried also to call home, because this is pretty serious:

Tue Apr 27 18:06:20 GMT [callhome.syncm.plex:CRITICAL]: Call home for SYNCMIRROR PLEX FAILED

Let’s verify again:

filerA> aggr status -r
Aggregate aggr_mirr (online, raid_dp, mirror degraded) (block checksums)
  Plex /aggr_mirr/plex0 (offline, failed, inactive, pool0)
    RAID group /aggr_mirr/plex0/rg0 (partial)

      RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------  ------------- ---- ---- ---- ----- --------------    --------------
      dparity   FAILED          N/A                        1020/2089984
      parity    FAILED          N/A                        1020/2089984
      data      FAILED          N/A                        1020/2089984
      Raid group is missing 3 disks.

  Plex /aggr_mirr/plex1 (online, normal, active, pool0)
    RAID group /aggr_mirr/plex1/rg0 (normal)

      RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------  ------------- ---- ---- ---- ----- --------------    --------------
      dparity   v1.25   v1    ?   ?   FC:A   0  FCAL  N/A  1020/2089984      1027/2104448
      parity    v5.26   v5    ?   ?   FC:B   0  FCAL  N/A  1020/2089984      1027/2104448
      data      v1.27   v1    ?   ?   FC:A   0  FCAL  N/A  1020/2089984      1027/2104448

[..]

During the whole PLEX destruction process, we were continually writing to NFS volume on this aggr_mirr, in synchronus mode (to avoid caching at OS level and to always hit the [NV]RAM – of course no NVRAM in simulator….), as you can see from below output, no single I/O error at all from NFS client perspective:

2097152 bytes (2.1 MB) copied, 0.498529 seconds, 4.2 MB/s
Thu Apr 29 16:10:32 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.51502 seconds, 4.1 MB/s
Thu Apr 29 16:10:33 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.514629 seconds, 4.1 MB/s
Thu Apr 29 16:10:35 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.419478 seconds, 5.0 MB/s
Thu Apr 29 16:10:36 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.411578 seconds, 5.1 MB/s
Thu Apr 29 16:10:38 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.444393 seconds, 4.7 MB/s
Thu Apr 29 16:10:39 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.43042 seconds, 4.9 MB/s
Thu Apr 29 16:10:41 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.417388 seconds, 5.0 MB/s
Thu Apr 29 16:10:42 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.504876 seconds, 4.2 MB/s
Thu Apr 29 16:10:44 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.425559 seconds, 4.9 MB/s
Thu Apr 29 16:10:45 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.453916 seconds, 4.6 MB/s
Thu Apr 29 16:10:46 CEST 2010
2+0 records in
2+0 records out
2097152 bytes (2.1 MB) copied, 0.417439 seconds, 5.0 MB/s

Posted In: NetApp, SAN | No Comments »

Storage migration for ASM database deployed on Oracle Enterprise Linux in Oracle VM without downtime.

Thursday, May 21st, 2009

Suppose you wanted to migrate your database from storage array SAN1 to SAN2 without downtime. With Oracle databases using ASM this is possible. It was performed on configuration better described here. One note: the LUN can be visible through dom0 or directly by domU (by passing PCI hardware handling into our domU VM) — this posts explains only first scenario, as this is more common scenario  Brief steps include:

  1. Prepare new LUNs on storage array (not described here)
  2. Attach new LUNs to the Oracle VM (not described here, simulated here by using simple zero-padded file created using dd utility; I expect this was performed earlier[scsi bus rescanning and so on] or file created in /OVS).
  3. Modifing VM’s XEN config file.
  4. Online attaching block device to VM.
  5. Preparing new storage device from inside of the target VM.
  6. Discovering new LUN in ASM.
  7. Actual rebalance process…
  8. Verification.

Step 3: Modify vm.cfg file for additional storage.

This is straighforward, just add one line. Do NOT restart the VM. There is no need.

[root@quadovm 01_prac1]# cat vm.cfg
bootloader = '/usr/bin/pygrub'
disk = ['file:/OVS/running_pool/01_prac1/system.img,hda,w',
'file:/OVS/running_pool/01_prac1/oracle_software.img,hdd,w',
'file:/OVS/running_pool/prac.storage.raw,hde,w!',
'file:/OVS/running_pool/prac.ocr,hdf,w!',
'file:/OVS/running_pool/prac.voting,hdg,w!'
<strong>'file:/OVS/running_pool/prac.storage2.raw,hdi,w!',</strong>
]
memory = 1638
name = '01_prac1'
[..]
[root@quadovm 01_prac1]#

Step 4: Attach block device to the running VM.

[root@quadovm 01_prac1]# xm block-attach 01_prac1 file:///OVS/running_pool/prac.storage2.raw /dev/hdi 'w!'
[root@quadovm 01_prac1]#

Step 5: Prepare prac1 VM for new device.

New added storage should be automatically detected, this can be verified by checking dmesg output:

[root@prac1 ~]# dmesg|grep hdi
hdi: unknown partition table
[root@prac1 ~]# ls -al /dev/hde /dev/hdi
brw-rw---- 1 root dba  33, 0 Jan 24 13:00 /dev/hde
brw-r----- 1 root disk 56, 0 Jan 24 12:59 /dev/hdi
[root@prac1 ~]#
[root@prac1 ~]# fdisk -l /dev/hd[ei] 2> /dev/null | grep GB
Disk /dev/hde: 15.7 GB, 15728640000 bytes
Disk /dev/hdi: 16.1 GB, 16106127360 bytes
[root@prac1 ~]#

As we can see new LUN is bigger (it should be bigger or equal, but I haven’t checked what happens if you add a smaller one). Now we have to assign correct permissions so that ASM/Database can use new /dev/hdi device without problems (this doesn’t include modifing udev rules in /etc/udev/, and it is required to make new devices come with right permissions after reboot — do your own home work:) ) :

[root@prac1 ~]# chgrp dba /dev/hdi
[root@prac1 ~]# chmod g+w /dev/hdi
[root@prac1 ~]#

Step 6: Preparing ASM for new disk.

Verification of current diskgroups and changing diskgroup DATA1 ASM_POWER_BALANCE to zero.

SQL> col name format a20
SQL> SELECT name, type, total_mb, free_mb, required_mirror_free_mb req_mirr_free, usable_file_mb FROM V$ASM_DISKGROUP;

NAME                 TYPE     TOTAL_MB    FREE_MB REQ_MIRR_FREE USABLE_FILE_MB
-------------------- ------ ---------- ---------- ------------- --------------
DATA1                EXTERN      15000      14143             0          14143

SQL> ALTER DISKGROUP DATA1 REBALANCE POWER 0 WAIT;

Diskgroup altered.

SQL>

Next we have to force ASM to discover new devices by modifing asm_diskstring parameter (I’m using IFILE for ASM, so I’ve to manually edit pfile for ASM. If I don’t, ASM won’t remember new settings after restarting).

SQL> show parameter string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring                       string      /dev/hde

SQL>
SQL> alter system set asm_diskstring='/dev/hde', '/dev/hdi' scope=memory;

System altered.

SQL> show parameter string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring                       string      /dev/hde, /dev/hdi

SQL>

[oracle@prac1 11.1.0]$ vi /u01/app/oracle/product/11.1.0/db_1/dbs/init+ASM1.ora
#Modify asm_diskstring here too
asm_diskstring='/dev/hde','/dev/hdi'

Step 7: The main part: ASM rebalance

SQL> ALTER DISKGROUP DATA1 ADD DISK '/dev/hdi';

Diskgroup altered.

SQL> SELECT GROUP_NUMBER, OPERATION, STATE FROM V$ASM_OPERATION;

GROUP_NUMBER OPERA STATE
------------ ----- --------------------
1 REBAL RUN

SQL> select name,path,state,failgroup from v$asm_disk;

NAME                 PATH            STATE                FAILGROUP
-------------------- --------------- -------------------- ----------
DATA1_0000     /dev/hde       NORMAL               DATA1_0000
DATA1_0001     /dev/hdi        NORMAL               DATA1_0001

SQL> ALTER DISKGROUP DATA1 DROP DISK DATA1_0000;

Diskgroup altered.

SQL> SELECT GROUP_NUMBER, OPERATION, STATE, EST_MINUTES FROM V$ASM_OPERATION;

GROUP_NUMBER  OPERA   STATE    EST_MINUTES
---------------------  ---------  ----------- -----------
1             REBAL    RUN        32 

SQL>

Typical snapshot of iostat right now (10 sec averages):

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
hde               0.00     0.00 340.80  1.10    14.20     0.00    85.08     1.43    4.18   0.35  12.04
hdi               0.00     0.00  0.40 357.40     0.01    14.28    81.77    11.52   32.22   2.40  86.04

From other normal SQL session:

SQL> insert into t2(id) values ('2');

1 row created.

SQL> commit;

Commit complete.

SQL>

Back to the ASM instance:

SQL> ALTER DISKGROUP DATA1 REBALANCE POWER 11;

Step 8: Verification.

We’ll just execute some big heavy-intensive SQL statement to generate some IO (thnx to Tanel for blogging this query):

SQL> create table t4 as select rownum r from
(select rownum r from dual connect by rownum <= 1000) a,
(select rownum r from dual connect by rownum <= 1000) b,
(select rownum r from dual connect by rownum <= 1000) c
where rownum <= 100000000;

From iostat we can monitor that only hdi is used, which assures us that database is really using hdi.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
33.33    0.00   26.47    5.88    0.00   34.31

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
hde               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
hdi               0.00     0.00 107.84 351.96     1.60    12.35    62.14     4.96   10.30   0.91  41.96

Posted In: Linux, Oracle ASM, OracleVM, SAN, XEN | No Comments »

My engineering work…

Wednesday, August 15th, 2007

As of May I’m very busy architecting & implementing cluster for Java Enterprise Edition on comodity hardware (mainly x86_32 based) for my engineering work – to obtain BEng title. Our subject is:
“Web service based on scalable and highly available J2EE application cluster”. We have team consisting of 4 persons in which I’m responsible for all kind of systems/hardware scaling/clusters/load balancing/databases/networking/tunning everything :) . What kind of portal we are creating is to be decided by developers (it will likely be some kind of Web 2.0 portal).
Rest of the team is dedicated to J2EE programming. We are mainly playing with technology.
Currently rock-solid base core cluster architecture looks like this:

Cluster architecture

We are utilizing:

  • Load balancers: Linux Virtual Servers with DirectRouting on CentOS5 (configured as a part of Redhat Cluster Suite)
  • Database: Oracle10g R2
  • Middleware: JBOSS 4.2.0 (EJB3) running in a cluster based on JGroups + Hibernate(JPA) + JBOSS Cache
  • Frontend: Apache2 webservers with Solaris Network Cache Accelerator and AJP proxy to JBOSS servers
  • Solaris Jumpstart to setup new systems really fast with our selfwritten application in PHP for maintaing systems.
  • NFS for providing static content for web servers from Oracle server (yay! dedicated NetApp would be great! ;) )
  • LDAP to synchronize admins accounts inside cluster.
  • SNMPv2(LVS,OSes,JBOSS,Oracle) to monitor everything with single (selfwritten) Java application which graphs everything in realtime.

As this is basic configuration with database as an single point of failure, in Septemer I’m going to setup DataGuard for Oracle. Also I’m testing more advanced scale up. Currently I’m in process of setting up Solaris Cluster with Oracle RAC 10gR2 implemented on iSCSI storage provided by third node based on Solaris Nevada with iSCSI target to test Transparent Application Failover. I’ve been scratching my head over this one for awhile now. Yeah, it is real hardcore… more over that’s not the end of the story – Disaster Recovery with some other interesting bits of technology is going to be implemented later on… all on x86_32 comodity hardware :) Also we are going to put C-JDBC(Sequoia project) under stress…

Posted In: J2EE, Linux, Oracle, SAN, Solaris, cluster | 2 Comments »

Exporting simple file from Linux target to Solaris initiatior using iSCSI

Friday, March 23rd, 2007

QuickHowTo about ”exporting” via iSCSI simple file from Linux target (ietd) to Solaris OS:

Linux target is running Debian/4.0, 2.6.18 kernel and iSCSI target version 0.4.14 – I wish it was Solaris box, but my very old home SCSI controllers aren’t supported by Solaris ( DELL MegaRAID 428 – PERC2 and InitIO ) – however there are some drivers but for Solaris 2.7-2.8, but after small war with them I must say that I failed…. even after playing hardcore stuff in /etc/driver_aliases

Installing iSCSI target on Debian is discussed here: Unofficial ISCSI target installation. Some checks:

rac3:/etc/init.d# cat /proc/net/iet/volume
tid:2 name:iqn.2001-04.com.example:storage.disk2.sys1.xyz
lun:0 state:0 iotype:fileio iomode:wt path:/u01/iscsi.target

rac3:/etc/init.d# cat /proc/net/iet/session
tid:2 name:iqn.2001-04.com.example:storage.disk2.sys1.xyz

As you can see /u01/iscsi.target is normal file ( created with dd(1) ) on MegaRAID RAID0 array. We will use it to do some testing from Solaris:


root@opensol:~# iscsiadm add static-config iqn.2001-04.com.example:storage.disk2.sys1.xyz,10.99.1.25
root@opensol:~# iscsiadm modify discovery --static enable
root@opensol:~# devfsadm -i iscsi
root@opensol:~# iscsiadm list target
Target: iqn.2001-04.com.example:storage.disk2.sys1.xyz
Alias: -
TPGT: 1
ISID: 4000002a0000
Connections: 1
root@opensol:~# format
Searching for disks...done

0. c1t0d0
/pci@0,0/pci1000,30@10/sd@0,0

1. c2t17d0
/iscsi/disk@0000iqn.200104.com.example%3Astorage.disk2.sys1.xyzFFFF,0
Specify disk (enter its number): CTRL+C


Okay so we are now sure that iSCSI works. In several days i'm going to test exporting SONY SDT-9000 ( an old tape drive ) via iSCSI :)

Posted In: Linux, SAN, Solaris | No Comments »

Kilka ciekawych linkow (Clustered Samba, CCIE.PL ciekawy post, drogie urzadzenia SAN ;) )

Sunday, March 18th, 2007

Samba nigdy zbytnio mnie nie interesowala ( bo nie interesowal mnie fakt udostepniania przestrzeni Windowsom ;) ) aczkolwiek ciekawie zapowiada sie klastrowana Samba.

Na forum CCIE.PL jest bardzo ciekawy wpis ( autor: pjeter ) ktory opisuje mniej wiecej sciaganie obrazu z tunera TV z kablowki i rzucanie tego na multicast w czasie rzeczywistym ( z kodekiem ) na zwyklym PC z Linuxem dzieki czemu obraz TV jest dostepny dla innych komputerow w sieci lokalnej…

Architektury sieci SAN mnie interesuja ( np link ) … ale niestety sa poza zasiegiem budzetowym:

  • MDS 9216 kosztuje ok 120000zl
  • o MDS 95xx lepiej wcale nie pisac ;)

Posted In: Linux, SAN, cluster | No Comments »