VSAN properties best practice

Hi all,
I would like to know the best way to configure the next properties (bolded and underlined):
show zone status:
                              VSAN: 1 default-zone: deny distribute: active only Interop: default
                                  mode: basic merge-control: allow
                                  session: none
                                  hard-zoning: enabled broadcast: unsupported
Best regards,
Igor.

some of it will depend on what features you like to use, for example here is mine:
VSAN: 14 default-zone: deny distribute: full Interop: default
   mode: basic merge-control: allow
    session: none
    hard-zoning: enabled broadcast: disabled
    smart-zoning: enabled
i have enabled full zoneset distribution, because i have switches ISL together, i want to propagates full zoneset information to all switches in the fabric that house VSAN 14. This would allow me to perform zoning for VSAN 14 from any switch in the fabric.
Smart-zoning - this is something new that was introduced in 5.2.6 code. It allows you to put multiple targets/initiators in the same zone and prevent targets from logging in into targets, and initiators logging in into initiators. Initially i was using zoning where each zone consisted of single initiator/single target but now i can put multiple targets in the same zone.
Mode Basic - i don't have many people on my team so "stepping on each other" while zoning is not an issue but for teams with a lot of members this could be beneficial, while you are zoning nobody else can make any changes to the fabric.
@dynamoxxx

Similar Messages

IVR (Inter-VSAN Routing) - Best practices questions

Hi there,
We have a situation where we will have multiple customers hosted on a 9513 and sharing a single storage array.
We want to keep the logically seperated in their own VSANs, but of course the storage array will need to be zoned to all the customers hosts.
Now IVR should be the thing to use, but I'm getting resistance from the local team (screams of "Nooooo!!! They're EVILLLLL!!!") ... so I want to find out if there are some best practices around IVR use ?
Should they be used only for light duty stuff ? (though at present we use them with tape backup, which isn't exactly "light")
Do they impact performance to a measurable degree ?
Are they stable ?
What can go wrong with them ? And does it happen often ?
Thanks!

IVR does not impact application I/O performance because all the vsan rewrite and fcid rewrite actions are done in hardware asics. The IVR process on supervisor is responsible for managing the configuration and ensuring the rewrite tables are programmed in the linecards. The process is stable.
Most of the issues I have seen are in environments with multiple IVR enabled MDS switches ISL'd together or an MDS IVR enabled switch connected to a McData/Brocade in an interop mode.
Like any feature there have been bugs and it pays to check the SAN-OS release notes when planning installs. For example, a config change on one switch does not get properly pushed to another IVR switch or a forwarding table for an ISL interface does not get correctly programmed. There have also been a fair share of user misconfigurations which could have been avoided if Cisco Fabric Services (CFS) was enabled for IVR. This is done with the 'ivr distribute' command. Without this it is very difficult in large topologies of multiple IVR switches to ensure they have a consistent IVR config. In other cases there have been problems from a mix of IVR enabled switches running different releases of SAN-OS, e.g. mixing 3.0 with 3.2.
Best practice is to have dual physical fabrics, upgrade one fabric at a time ensuring all IVR switches in a fabric run same SAN-OS release.
A single IVR switch is much easier to implement. The MDS Configuration Guide has a list of best practices for IVR and one of those is to use the NAT option. Personally I would avoid NAT option where you can as NAT makes any troubleshooting harder trying to figure out the domain ID translations. You would also minimize risk of hitting some NAT related bugs, but you could also avoid most of these by checking the workarounds documented in the Release Notes. And with NAT you need to also configure persistent virtual domains and fcids to cater for AIX and HP-UX systems that cannot handle the FCID of the target changing whenever the exported virtual domain ID changes. To give NAT credit, each vsan is represented by a single virtual domain. In regular non-NAT mode, each switch in a vsan is represented by a virtual domain, meaning you eat up more virtual domain IDs. So in large topologies with many domain IDs there are scalability advantages to using NAT and the IVR updates between switches are more efficient with fewer virtual domain IDs to advertize. Of course, NAT must be used if merging physical fabrics with same domain ID and you cannot afford the downtime to change one of the switch domain IDs.
However if it is just a single IVR switch I would avoid NAT. To do this all your domain IDs should be statically defined and there must be no overlapping domain IDs between IVR'd vsans. If it is a brand new install you can easily achieve this by specifying unique allowed domain ID ranges per vsan.
For example, each customer can have their own vsan with say 10 domain IDs and the storage can be in vsan 2. You will only use one domain ID per vsan on day 1. Allowing 10 domain ids per vsan means you can add up to 9 other switches per vsan should you need to in the future. There is a maximum 239 domains per vsan so you could have up to 23 customers on your 9513 working with a range of 10 domain IDs per vsan.
fcdomain domain 2 static vsan 2
fcdomain domain 10 static vsan 10
fcdomain domain 20 static vsan 20
fcdomain domain 30 static vsan 30
..and so on..
fcdomain domain 230 static vsan 230
fcdomain allowed 01-09 vsan 2
fcdomain allowed 10-19 vsan 10
fcdomain allowed 20-29 vsan 20
fcdomain allowed 30-39 vsan 30
..and so on..
fcdomain allowed 230-239 vsan 230
With or without IVR you should still run dual fabrics (e.g. 95xx in each fabric) and host based multipathing for redundancy.
And don't forget IVR will require an Enterprise license. I have even seen a large outage because the customer forgot to install the license before the 120 day grace period expired.

Properties: Best Practice

This question is intended to be less specific and more of a general good practice topic.
In my application I have a series of Views that receive an object that contains properties that will affect how the View is displayed. Considering that the flow of the program is linear, there is no reason to +have to+ allow the code to GET the object out of the view after it has been set excluding local instance calls. For that reason, I chose not to use properties and instead to only explicitly define a setter for the object. What I am wondering is if it makes more sense to use the convenience of a property and remove some of the encapsulation of the View. Really, there is no distinctly valuable advantage to doing it the way I have or with a property instead (as far as I can tell), but I'd be curious to know if this approach is not considered ideal.
Thanks

AFAIK you can also set a property to write-only access...?! Am I wrong here?
But - besides - if only you are using this code than it might be not worth the effort to write the setter on your own if you can use properties instead. Encapsulation, IMHO, is only really necessary if you share your code to make it easier to use or if your source gets so big or crowded or whatever that you dont understand it yourself after a day
But...yet on the other side I'm not that much of the strict-coding-rules-type of guy... ;o)

Best practice using regular properties

What is considered best practice when it comes to using properties ? Example like hostname, port number when connecting towards an external resource.
Should property files be used ? Is this considered a bad practice ? Should deployment descriptors be used - if so - how do one update these properties when changed ?
Are there any utility classes that makes easy access to this kind of properties ?
---- Trond

Depends on what properties. Many properties like hostname etc can be retrieved using different API calls - such as the request object or other portal specific objects.
Properties that you applications need, that might change - can be stored in a properties file. I use a singleton to retreive them - and have a reload method on the singleton that I can call if I need to reload the properties once the server has started.
Kunal

Best Practice on trunking VSAN 1

Hello all
I'd appreciate feedback on wether this is looked upon as good practice or not.
For all the Cisco SAN implementations I have done to date, I have always trunked VSAN1 (but obviously NOT used it for customer data). I do this for a couple of reasons.
1. It is a good test for an ISL, you can initially trunk VSAN1 to be 100% all is OK, before affecting customer VSAN's
2. Fabric manager is not "erroring" by reporting segmented VSAN's
What do the rest of you do? Is there a Cisco best practice on this?
Thanks
Steven

Steven,
CFS stands for Cisco Fabric Services. It can be used to distribute configuration information between MDS switches to keep the configuration consistent. It can be used for various things like NTP settings, Syslog config, call home config etc.
You can find more information in the MDS documentation on CCO. See here for example:
http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/sw/5_0/configuration/guides/sysmgnt/nxos/cfs.html
CFS uses VSAN 1.
As for best practices, there is a document also on CCO:
http://www.cisco.com/en/US/prod/collateral/ps4159/ps6409/ps5990/white_paper_C11-515630.html
This talks a bit about VSAN 1. I can tell you that I have installed lots of MDS SANs during the past 9 years and it is one of the things I’d do from experience. Use VSAN 1 for management purposes like CFS and put your real production traffic in other VSANs.
Ralf

Best Practices - Update Explorer Properties of BW Objects

What are some best practices of using the process chain type "Update Explorer Properties of BW Objects"?
We have the option of updating Conversion Indexes, Hierarchy Indexes, Authorization Indexes, and RKF/CKF Indexes.
When should we run each update process?
Here are some options we're considering:
Conversion Indexes - Run this within InfoCube load process chains that contain currency conversions within explorer objects.
Hierarchy Indexes - When would this need to be run? Does this need to be run for PartProviders and/or Snapshots? Do ACRs handle this update? Should this be run within InfoCube load chains, or after ACRs?
Authorization - We plan to run this a couple times a day for all explorer objects.
RKF/CKS - Does this need to run after InfoCube loads? With PartProvider and/or Snapshot indexes? After transports have completed?
Thanks,
Cote

Does anyone productively use explorer and this process type for process chains?

Best Practice Needed: Global Application Properties...

Hi All,
When developing a web-based application that reads certain configurable parameters from .properties files, I usually put the appropriate code in a static block in the appropriate Java class, storing the property in a static final constant. For example, a DBConnection class might have a static block that reads the driver, username, and password from a properties file.
My question is, what are some "best practice" techniques for accessing and storing such parameters for use in an application? Are all global properties initialized in one class? at the same time? only when first needed?

over all, I would say that your approach is fine. Personally, I load properties through a single class, some thing like PropertyReader, and have the different classes initialize their static fields via a get method on that class, like getProperty("db.user"). I prefer to load them via a single class because I can place all of my IO trapping in one location, it is easier to implement new security measures and, if necessary, easier to support internationalization.
I initialize all properties once, at startup, into a Wrapper Object, typically ResourceBundle or Properties (although Hashtable or any some thing else would be suitable). I believe that it is best to initialize all properties at the same time, at startup because the costs of storing properties that may not be used is going to be less then the cost of making multiple IO calls to load properties on a need-by-need basis. In other words, you are almost always going to take a bigger performance hit by loading properties only when a request for that key is received, rather then just loading them all at once.

Constants or properties file - best practice question

Hi,
My application has a number of values that will be used in different classes throughout my project. For example, I perform a check against the max allowed length of an ID in numerous places in my code.
Therefore, it makes sense to set this value in a central location, and refer to it as a variable where it is required in my code.
I see in other projects that using a public static final member in a Constants class is used to set these types of values. Is this recommended or best practice?
The only alternative I can think of would be to use a properties file, and inject the value using Spring etc.
What is considered best practice or the neatest way for doing this?
Thanks

user10340197 wrote:
Thanks. I'm using Spring anyways, so it would provide me with the PropertyPlaceHolderConfigurer for injecting these.And the name of that class provides a clue. As Kayaman said, constants are constants. Math.PI does not and will not change, EVER. Neither will Integer.MAX_VALUE.
Configuration parameters, on the other hand, might change. If your MAX_ID_LENGTH is ever likely to change, and could do so without causing widespread chaos, then it probably should be a property (ie, a configuration) value.
If not, it should probably be a constant (with appropriate 60-point documentation warning people what might happen if they DO change it).
Winston
PS: There is nothing particularly terrible about having a Properties class (except that you'll want to call it something different) that initializes its values from configuration files; except that if there are gazillions of them, you might want to:
(a) Split them up into "themes".
(b) Re-think your design.
Winston

Best practice to move things between various environments in SharePoint 2013

Hi All SharePoint Gurus!! - I was using SP deployment wizard to move Sites/lists/libraries/items etc. using SP Deployment Wizard (spdeploymentwizard.codeplex.com) in SP 2010. We just upgraded to SP 2013. I have few Lists and Libraries that I need to push
into the Staging 2013 and Production 2013 environment from Development 2013 environment. SP Deployment Wizard is throwing error right from the startup. I checked SP 2013 provides granular backups but is restricted to Lists/Library level. Could anybody
let me know if SP Deployment Wizard works for 2013? I love that tool. Also, Whats the best practice to move things between various environments?
Regards,
Khushi
Khushi

Hi Khushi,
I want to let you know that we built
SharePoint Migration tool
MetaVis Migrator that can copy and migrate to and from on-premise or hosted SharePoint sites. The tool can copy entire
sites with sub-site hierarchies, content types, fields, lists, list views, documents, items with attachments, look and feel elements, permissions, groups and other objects - all together on at any level of granularity (for
example, just lists or just list views or selected items). The tool preserves created / modified properties, all metadata and versions. It looks like Windows Explorer with copy/paste and drag-n-drop functions so it is easy to learn. It does not require any
server side installations so you can do everything using your computer or any other server. The tool can copy the complete sites or just individual lists or even selected items. The tool also supports incremental or delta copy based on the previous migrations.
The tool also includes Pre-Migration Analysis that helps to identify customizations.
Free trial is available:
http://www.metavistech.com . Feel free to contact us.
Good luck with your migration project,
Mark

Best Practice in using Business Packages

Hi All,
Are there any Best Practices in the use of Business Package content? Do you assign the Roles delivered by the Business Package and do you make changes to the original iViews?
or
Do you copy the content delivered in the Business Package to a new folder and work with there?
These questions are purely at the configuration level and not at the Java coding level. For instance if I want to turn of the iView Tray, or change a parameter such as height, or even remove an iView from a page or Role.
I would like to know the various approaches the SDN community uses and the different challenges and benefits that result in each approach.
Look forward to hearing from you all
Paul

Hi Paul,
I also build my own roles. The only time I might use the standard roles is for demo purposes early in a project. You will find that in some cases the business packages like MSS don't always even include standard roles, so you have no choice but to build.
I never change any of the standard iViews/Pages/Worksets - ever.
The most contentious issue seems to be whether to do a full or delta link copy of the standard objects. I tend to initially do a full copy of the objects into a custom folder set in the PCD and modify those. Then I only use delta links from Page to iViews where I need the option of setting different properties for the same iView if it appears in multiple pages. Delta links can be a bit flakey at times, so I tend to only use them where I have to. I suspect that I may get to a point where I don't use them at all.
Just my 2 cents worth....
Regards,
John

Best Practices:: How to generate XML file from a ResultSet

Hi all,
Could someone please suggest the best practices of how to generate an XML file from a resultset? I am developing a web application in Java with Oracle database and one of my tasks is to generate an XML file when the user, for example, click a "download as XML" button on the JSP. The application is basically like an Order with line items. I am using Struts and my first thought has been to have an action class which will extend struts's DownloadAction and through StAX's Iterator API to create an XML file. I intend to have a POJO which will have properties of all columns of my order and line items tables so that for each order I get all line items and:
1. Write order details then
2. Through an iterator write line items of that order to an XML file.
I will greatly appreciate for comments or suggestions on the best way to do this through any pointers on the Web.
alex

Use a OracleWebRowSet in which an XML representation of the result set may be obtained.
http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/oracle10g/webrowset/Readme.html
http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/jcrowset.htm

Best practices for setting up projects

We recently adopted using Captivate for our WBT modules.
As a former Flash and Director user, I can say it’s
fast and does some great things. Doesn’t play so nice with
others on different occasions, but I’m learning. This forum
has been a great source for search and read on specific topics.
I’m trying to understand best practices for using this
product. We’ve had some problems with file size and
incorporating audio and video into our projects. Fortunately, the
forum has helped a lot with that. What I haven’t found a lot
of information on is good or better ways to set up individual
files, use multiple files and publish projects. We’ve decided
to go the route of putting standalones on our Intranet. My gut says
yuck, but for our situation I have yet to find a better way.
My question for discussion, then is: what are some best
practices for setting up individual files, using multiple files and
publishing projects? Any references or input on this would be
appreciated.

Hi,
Here are some of my suggestions:
1) Set up a style guide for all your standard slides. Eg.
Title slide, Index slide, chapter slide, end slide, screen capture,
non-screen capture, quizzes etc. This makes life a lot easier.
2) Create your own buttons and captions. The standard ones
are pretty ordinary, and it's hard to get a slick looking style
happening with the standard captions. They are pretty easy to
create (search for add print button to learn how to create
buttons). There should instructions on how to customise captions
somewhere on this forum. Customising means that you can also use
words, symbols, colours unique to your organisation.
3) Google elearning providers. Most use captivate and will
allow you to open samples or temporarily view selected modules.
This will give you great insight on what not to do and some good
ideas on what works well.
4) Timings: Using the above research, I got others to
complete the sample modules to get a feel for timings. The results
were clear, 10 mins good, 15 mins okay, 20 mins kind of okay, 30
mins bad, bad, bad. It's truly better to have a learner complete
2-3 short modules in 30 mins than one big monster. The other
benefit is that shorter files equal smaller size.
5) Narration: It's best to narrate each slide individually
(particularly for screen capture slides). You are more likely to
get it right on the first take, it's easier to edit and you don't
have to re-record the whole thing if you need to update it in
future. To get a slicker effect, use at least two voices: one male,
one female and use slightly different accents.
6) Screen capture slides: If you are recording filling out
long window based databse pages where the compulsory fields are
marked (eg. with a red asterisk) - you don't need to show how to
fill out every field. It's much easier for the learner (and you) to
show how to fill out the first few fields, then fade the screen
capture out, fade the end of the form in with the instructions on
what to do next. This will reduce your file size. In one of my
forms, this meant the removal of about 18 slides!
7) Auto captions: they are verbose (eg. 'Click on Print
Button' instead of 'Click Print'; 'Select the Print Preview item'
instead of 'Select Print Preview'). You have to edit them.
8) PC training syntax: Buttons and hyperlinks should normally
be 'click'; selections from drop down boxes or file lists are
normally 'select': Captivate sometimes mixes them up. Instructions
should always be written in the correct order: eg. Good: Click
'File', Select 'Print Preview'; Bad: Select 'Print Preview' from
the 'File Menu'. Button names, hyperlinks, selections are normally
written in bold
9) Instruction syntax: should always be written in an active
voice: eg. 'Click Options to open the printer menu' instead of
'When the Options button is clicked on, the printer menu will open'
10) Break all modules into chapters. Frame each chapter with
a chapter slide. It's also a good idea to show the Index page
before each chapter slide with a progress indicator (I use an
animated arrow to flash next to the name of the next chapter), I
use a start button rather a 'next' button for the start of each
chapter. You should always have a module overview with the purpose
of the course and a summary slide which states what was covered and
they have complete the module.
11) Put a transparent click button somewhere on each slide.
Set the properties of the click box to take the learner back to the
start of the current chapter by pressing F2. This allows them to
jump back to the start of their chapter at any time. You can also
do a similar thing on the index pages which jumps them to another
chapter.
12) Recording video capture: best to do it at normal speed
and be concious of where your mouse is. Minimise your clicks. Most
people (until they start working with captivate) are sloppy with
their mouse and you end up with lots of unnecessarily slides that
you have to delete out. The speed will default to how you recorded
it and this will reduce the amount of time you spend on changing
timings.
13) Captions: My rule of thumb is minimum of 4 seconds - and
longer depending on the amount of words. Eg. Click 'Print Preview'
is 4 seconds, a paragraph is longer. If you creating knowledge
based modules, make the timing long (eg. 2-3 minutes) and put in a
next button so that the learner can click when they are ready.
Also, narration means the slides will normally be slightly longer.
14) Be creative: Capitvate is desk bound. There are some
learners that just don't respond no matter how interactive
Captivate can be. Incorporate non-captivate and desk free
activities. Eg. As part of our OHS module, there is an activity
where the learner has to print off the floor plan, and then wander
around the floor marking on th emap key items such as: fire exits;
first aid kit, broom and mop cupboard, stationary cupboard, etc.
Good luck!

What is the best practice for changing view states?

I have a component with two Pie Charts that display
percentages at two specific dates (think start and end values).
But, I have three views: Start Value only, End Value only, or show
Both. I am using a ToggleButtonBar to control the display. What is
the best practice for changing this kind of view state? Right now
(since this code was inherited), the view states are changed in an
ActionScript function which sets the visible and includeInLayout
properties on each Pie Chart based on the selectedIndex of the
ToggleButtonBar, but, this just doesn't seem like the best way to
do this - not very dynamic. I'd like to be able to change the state
based on the name of the selectedItem, in case the order of the
ToggleButtons changes, and since I am storing the name of the
selectedItem for future reference.
Would using States be better? If so, what would be the best
way to implement this?
Thanks.

I would stick with non-states, as I have always heard that
states are more for smaller components that need to change under
certain conditions, like a login screen that changes if the user
needs to register.
That said, if the UI of what you are dealing with is not
overly complex, and if it will not become overly complex, maybe
states is the way to go.
Looking at your code, I don't think you'll save much in terms
of lines of code.

External System Authentication Credentials Best practice

We are in the process of an 5.0 upgrade.
We are using NTLM as our authentication source to get teh users and the groups and authenticate against the source. So currently we only have the NT userid, group info(NT domain password is not stored).
We need to get user credentials to other systems/applications so that we can pass that on the specfic applications when we search/crawl or integrate with those apps/systems.
We were thinking of getting the credentials(App userid and password) for other applications by developing a custom Profile Web service to gather the information specific to these users. However, don't know if external application password is secured when retrieving from the external repository via a PWS and storing into the Portal database.
Is this the best approach to take to gather the above information? If not, please recommend the best practice to follow.
Alternatively, can have the users enter the external system credentials by having them edit their user profile. However, this approach is not preferred.
If we can't store the user credential to the external apps, we won't eb able to enhance the user experience when doing a search/or click-thorugh to tthe other applications.
Any insight would be appreciated.
Thanks.
Vanita

Hi Vanita,
So your solution sounds fine - however, it might be easier to use an SSO Token or the Plumtree UserID in your external applications as a difinitive authentication token.
For example if you have some external application that requires a username and password, then if you are in a portlet view of the application the application should be able to take the userid plumtree sends it to authenticate that it is the correct user. You should limit this sort of password bypass to traffic being gatewayed by the portal (i.e. coming from the portal server only).
If you want to write a Profile Web Service, the data the gets stored in the Plumtree Database is exactly what the Profile Web Service send it as the value for a particular attribute. For example if your PWS tells Plumtree that the APP1UserName and APP1Password for user My Domain\Akash is Akash and password then that is what we save. If your PWS encrypts the password using some 2-way encryption before hand, then that is what we will save. These properties are simply attached to the user, and can be sent to different portlets.
Hope this helps,
-aki-

Best practice for integrating oracle atg with external web service

Hi All
What is the best practice for integrating oracle atg with external web service? Is it using integration repository or calling the web service directly from the java class using a WS client?
With Thanks & Regards
Abhishek

Using Integration Repository might cause performance overhead based on the operation you are doing, I have never used Integration Repository for 3rd Party integration therefore I am not able to make any comment on this.
Calling directly as a Java Client is an easy approach and you can use ATG component framework to support that by making the endpoint, security credentials etc as configurable properties.
Cheers
R
Edited by: Rajeev_R on Apr 29, 2013 3:49 AM

VSAN properties best practice

Similar Messages

Maybe you are looking for