aggr0 - adding disks and creating volume for data

[RogerT]

Hi,

I am new to Netapp.

We recently bought 2 filers with 12 disks each : FAS2552  - NetApp Release 8.2.3P3 7-Mode

Since the aggr  already took 6 disks (3 for each controller), I am thinking of  simply adding the remaining 6 disks to it and create my data volume there (alongside the root volume).

Is this recommended ?  if not, are there any issues with regard to system stabliity and performance that I need to be aware of ?

thanks in advance.

[JGPSHNTAP]

Man that's an awfully small purchase.. 

What size drives?

And with that # of drives, you want to combine aggr0

[RogerT]

yes.  the purpose of these 2 systems was only for functional testing.  Actual customer has the higher end systems with much more disk.

the disks on these are 10k 900GB each.

If I do create new aggregate with double parity, then I will only get  2.2 TB out of those 6 remaining disks.

[Premkumar]

Hello,

As per the Netapps recommendation, not to keep the user data on Root volume aggregate. please keep in mind.

yes you can add the similier type and Size of HDD on aggr0.

Also can get higher capacity of SAS HDD in the market and create the new aggregate for new aggregate and volumes. 

Thanks.

[DaemonFF]

---

@RogerT wrote:

We recently bought 2 filers with 12 disks each : FAS2552  - NetApp Release 8.2.3P3 7-Mode

Since the aggr  already took 6 disks (3 for each controller), I am thinking of  simply adding the remaining 6 disks to it and create my data volume there (alongside the root volume).

Is this recommended ?  if not, are there any issues with regard to system stabliity and performance that I need to be aware of ?

---

Hi, Roger!

It has been not recommended to place data on the root aggregate by security reasons. If You need to save the data space, You may going to Clustered OnTAB 8.3 (now availiable 8.3.2P4) and use advanced data partition feature. Keep in mind that this transition needs to data evacuation.

Best regards, Serge.

[SeanHatfield]

If going to cluster mode is an option, then reinitializing the system on 8.3 or later with advanced drive partitioning would be ideal.

If you need to stay on 7mode, which may be the case since these are for functional testing and likely need to match the client configuration/ONTAP release as much as possible, then you've got a few choices:

Active/Idle with shared root aggregate 

Active/Idle with dedicated root aggregate

Active/Active with shared root aggregate

Active/Active with dedicated root aggregate

Shared root aggregates are not ideal, but it was a common compromise on entry level 7mode platforms.

Active/Idle configurations give you a single larger pool of capacity and performance.

It comes down to what your priorities are and how you intend to use the systems.

[JGPSHNTAP · Accepted solution]

As I stated earlier, with 7-mode, there is no issue on a smaller system with adding disks to root aggr.  It's been a common practice for many years...   For that people that just know cDOT, you cant do it in cdot.  

[illllm]

Since this is for functional testing, and probably you want to implement this in production, test it like you would design in production:

1. Create a new aggr , maybe aggr2

2. create volumes in this new aggr

NetApp strongly does not recommend using the root aggr. If your production environment ends up with issues, this will be the first issue you will need to fix with NetApp support. Create a new Aggr.

[aborzenkov]

---

@illllm wrote:

If your production environment ends up with issues, this will be the first issue you will need to fix with NetApp support. Create a new Aggr.

---

Come on, really. Do you have any evidence to prove this statement?

[JGPSHNTAP]

@aborzenkov

We have been around a long time, so you can listen to us

[RogerT]

Thanks to all for the advices.

These systems are dev use only.   We can take the risk of encountering issues since it only store test data.   For production customers,  the systems have plenty of disks to create new aggregates and leave the root aggregate alone.

thanks again.

Roger