Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray - Unix

This is a discussion on Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray - Unix ; Our servers run Solaris 10 with Symantec/Veritas Storage Foundation for Oracle (version 3.5 to 5.0). We are requesting 600Gb luns, i.e., 4 x 125Gb luns at the new Hitachi's USP-V storage array. We plan to create 4 Veritas file systems, ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray

  1. Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray

    Our servers run Solaris 10 with Symantec/Veritas Storage Foundation
    for Oracle (version 3.5 to 5.0). We are requesting 600Gb luns, i.e.,
    4 x 125Gb luns at the new Hitachi's USP-V storage array. We plan to
    create 4 Veritas file systems, each with an associated volume and luns
    of size 125Gb.

    Our storage team is using "dynamic/thin provisioning" to allocate the
    luns for us. What is "dynamic/think provisioning" ? Any pros and
    cons with "dynamic provisioning" ? Will our server see the four
    125Gb luns as usual in "format" ? Is there any housekeeping or on-
    going admins commands to issue if we need to expand the file system's
    size down the road or to do any maintainence work ? Can we still
    create new Veritas diskgroups, disks, volumes and file systems as
    usual under "dynamic provisioning" ?

    Please let me know if you have any further information regarding this
    topic.


    Thanks,

    Bill

  2. Re: Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray

    On Mar 5, 6:26*pm, underh20.scubadiv...@gmail.com wrote:
    > Our servers run Solaris 10 with Symantec/Veritas Storage Foundation
    > for Oracle (version 3.5 to 5.0). *We are requesting 600Gb luns, i.e.,
    > 4 x 125Gb luns at the new Hitachi's USP-V storage array. *We plan to
    > create 4 Veritas file systems, each with an associated volume and luns
    > of size 125Gb.
    >
    > Our storage team is using "dynamic/thin provisioning" to allocate the
    > luns for us. *What is "dynamic/think provisioning" ? *Any pros and
    > cons with "dynamic provisioning" *? *Will our server see the four
    > 125Gb luns as usual in "format" ? *Is there any housekeeping or on-
    > going admins commands to issue if we need to expand the file system's
    > size down the road or to do any maintainence work ? *Can we still
    > create new Veritas diskgroups, disks, volumes and file systems as
    > usual under "dynamic provisioning" ?
    >
    > Please let me know if you have any further information regarding this
    > topic.
    >
    > Thanks,
    >
    > Bill


    In Dynamic or Thin provisioning the array tells the host it has 4 x
    125G LUNS. It does not set aside all the space until the host wants to
    actually write data there. The thought is few people want a filesystem
    100% full. This extra bit of space is wasted on every server. If I
    make it look like you have the space (and you COULD use it, if needed)
    but don't actually allocate it, then I'm saving SAN space per server.
    I keep a little extra space on the array to handle a spike from any
    server, then life is great!

    How does this effect your LVM? Short Answer - It doesn't. The host
    actually thinks the 4 LUNS of 125G are actually all there. You could
    make them all be there, if you wish, but there isn't alot of point in
    that, right? Just treat them like 4x125GB LUNS for LVM and life will
    be grand.

    The danger with Thin Provisioning is over allocating. Some arrays
    prevent this from happening, others will let you. That is when you
    have 1 TB, promise 256GB to 6 hosts. It's okay, until the hosts want
    more than 1TB combined.

    In the end you have to trust the SAN guys like the DBAs (and other app
    ppls) have to trust the Unix Admins.

  3. Re: Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray

    On Mar 5, 6:26*pm, underh20.scubadiv...@gmail.com wrote:
    > Our servers run Solaris 10 with Symantec/Veritas Storage Foundation
    > for Oracle (version 3.5 to 5.0). *We are requesting 600Gb luns, i.e.,
    > 4 x 125Gb luns at the new Hitachi's USP-V storage array. *We plan to
    > create 4 Veritas file systems, each with an associated volume and luns
    > of size 125Gb.
    >
    > Our storage team is using "dynamic/thin provisioning" to allocate the
    > luns for us. *What is "dynamic/think provisioning" ? *Any pros and
    > cons with "dynamic provisioning" *? *Will our server see the four
    > 125Gb luns as usual in "format" ? *Is there any housekeeping or on-
    > going admins commands to issue if we need to expand the file system's
    > size down the road or to do any maintainence work ? *Can we still
    > create new Veritas diskgroups, disks, volumes and file systems as
    > usual under "dynamic provisioning" ?
    >
    > Please let me know if you have any further information regarding this
    > topic.
    >
    > Thanks,
    >
    > Bill


    In Dynamic or Thin provisioning the array tells the host it has 4 x
    125G LUNS. It does not set aside all the space until the host wants to
    actually write data there. The thought is few people want a filesystem
    100% full. This extra bit of space is wasted on every server. If I
    make it look like you have the space (and you COULD use it, if needed)
    but don't actually allocate it, then I'm saving SAN space per server.
    I keep a little extra space on the array to handle a spike from any
    server, then life is great!

    How does this effect your LVM? Short Answer - It doesn't. The host
    actually thinks the 4 LUNS of 125G are actually all there. You could
    make them all be there, if you wish, but there isn't alot of point in
    that, right? Just treat them like 4x125GB LUNS for LVM and life will
    be grand.

    The danger with Thin Provisioning is over allocating. Some arrays
    prevent this from happening, others will let you. That is when you
    have 1 TB, promise 256GB to 6 hosts. It's okay, until the hosts want
    more than 1TB combined.

    In the end you have to trust the SAN guys like the DBAs (and other app
    ppls) have to trust the Unix Admins.

  4. Re: Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray

    edcrosbys wrote:
    > On Mar 5, 6:26 pm, underh20.scubadiv...@gmail.com wrote:
    >> Our servers run Solaris 10 with Symantec/Veritas Storage Foundation
    >> for Oracle (version 3.5 to 5.0). We are requesting 600Gb luns, i.e.,
    >> 4 x 125Gb luns at the new Hitachi's USP-V storage array. We plan to
    >> create 4 Veritas file systems, each with an associated volume and luns
    >> of size 125Gb.
    >>
    >> Our storage team is using "dynamic/thin provisioning" to allocate the
    >> luns for us. What is "dynamic/think provisioning" ? Any pros and
    >> cons with "dynamic provisioning" ? Will our server see the four
    >> 125Gb luns as usual in "format" ? Is there any housekeeping or on-
    >> going admins commands to issue if we need to expand the file system's
    >> size down the road or to do any maintainence work ? Can we still
    >> create new Veritas diskgroups, disks, volumes and file systems as
    >> usual under "dynamic provisioning" ?
    >>
    >> Please let me know if you have any further information regarding this
    >> topic.
    >>
    >> Thanks,
    >>
    >> Bill

    >
    > In Dynamic or Thin provisioning the array tells the host it has 4 x
    > 125G LUNS. It does not set aside all the space until the host wants to
    > actually write data there. The thought is few people want a filesystem
    > 100% full. This extra bit of space is wasted on every server. If I
    > make it look like you have the space (and you COULD use it, if needed)
    > but don't actually allocate it, then I'm saving SAN space per server.
    > I keep a little extra space on the array to handle a spike from any
    > server, then life is great!
    >
    > How does this effect your LVM? Short Answer - It doesn't. The host
    > actually thinks the 4 LUNS of 125G are actually all there. You could
    > make them all be there, if you wish, but there isn't alot of point in
    > that, right? Just treat them like 4x125GB LUNS for LVM and life will
    > be grand.
    >
    > The danger with Thin Provisioning is over allocating. Some arrays
    > prevent this from happening, others will let you. That is when you
    > have 1 TB, promise 256GB to 6 hosts. It's okay, until the hosts want
    > more than 1TB combined.
    >
    > In the end you have to trust the SAN guys like the DBAs (and other app
    > ppls) have to trust the Unix Admins.


    Please remember that This Provisioning for Oracle might not have sense
    because usually DBA preallocate the whole space for tablespaces.

    Regards
    przemol

    --
    http://przemol.blogspot.com/

  5. Re: Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray

    edcrosbys wrote:
    > On Mar 5, 6:26 pm, underh20.scubadiv...@gmail.com wrote:
    >> Our servers run Solaris 10 with Symantec/Veritas Storage Foundation
    >> for Oracle (version 3.5 to 5.0). We are requesting 600Gb luns, i.e.,
    >> 4 x 125Gb luns at the new Hitachi's USP-V storage array. We plan to
    >> create 4 Veritas file systems, each with an associated volume and luns
    >> of size 125Gb.
    >>
    >> Our storage team is using "dynamic/thin provisioning" to allocate the
    >> luns for us. What is "dynamic/think provisioning" ? Any pros and
    >> cons with "dynamic provisioning" ? Will our server see the four
    >> 125Gb luns as usual in "format" ? Is there any housekeeping or on-
    >> going admins commands to issue if we need to expand the file system's
    >> size down the road or to do any maintainence work ? Can we still
    >> create new Veritas diskgroups, disks, volumes and file systems as
    >> usual under "dynamic provisioning" ?
    >>
    >> Please let me know if you have any further information regarding this
    >> topic.
    >>
    >> Thanks,
    >>
    >> Bill

    >
    > In Dynamic or Thin provisioning the array tells the host it has 4 x
    > 125G LUNS. It does not set aside all the space until the host wants to
    > actually write data there. The thought is few people want a filesystem
    > 100% full. This extra bit of space is wasted on every server. If I
    > make it look like you have the space (and you COULD use it, if needed)
    > but don't actually allocate it, then I'm saving SAN space per server.
    > I keep a little extra space on the array to handle a spike from any
    > server, then life is great!
    >
    > How does this effect your LVM? Short Answer - It doesn't. The host
    > actually thinks the 4 LUNS of 125G are actually all there. You could
    > make them all be there, if you wish, but there isn't alot of point in
    > that, right? Just treat them like 4x125GB LUNS for LVM and life will
    > be grand.
    >
    > The danger with Thin Provisioning is over allocating. Some arrays
    > prevent this from happening, others will let you. That is when you
    > have 1 TB, promise 256GB to 6 hosts. It's okay, until the hosts want
    > more than 1TB combined.
    >
    > In the end you have to trust the SAN guys like the DBAs (and other app
    > ppls) have to trust the Unix Admins.


    Please remember that This Provisioning for Oracle might not have sense
    because usually DBA preallocate the whole space for tablespaces.

    Regards
    przemol

    --
    http://przemol.blogspot.com/

  6. Re: Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray

    On Mar 7, 2:12*am, przemol wrote:
    > Please remember that This Provisioning for Oracle might not have sense
    > because usually DBA preallocate the whole space for tablespaces.
    >
    > Regards
    > przemol
    >
    > --http://przemol.blogspot.com/


    True, although I believe best practice has them allocating more than
    currently needed, and setting up autoextents with notification.
    Although my DBA-fu isn't as keen as it used to be.

  7. Re: Question: Dynamic / Thin Provisioning at Hitachi's USP-V storagearray

    On Mar 7, 2:12*am, przemol wrote:
    > Please remember that This Provisioning for Oracle might not have sense
    > because usually DBA preallocate the whole space for tablespaces.
    >
    > Regards
    > przemol
    >
    > --http://przemol.blogspot.com/


    True, although I believe best practice has them allocating more than
    currently needed, and setting up autoextents with notification.
    Although my DBA-fu isn't as keen as it used to be.

+ Reply to Thread