So every now and then I get the question if it is possible to access the BNA database in order to get info which then can be used to fill an excel spreadsheet for reference purposes. The though process is that often BNA/Storage administrators don’t want server admins to fool around in BNA and accidentally make changes or configuration mistakes but in the same time be able to provide insight in the SAN from a install base and configuration perspective. Although there is nothing wrong with the intent of that thought the method is however very questionable.
Providing direct access to a database is often seen as a quick and dirty way to get to the info but when it comes to accuracy it is not the way to go. Be aware that the information as obtained via the database is scattered over numerous tables and you really have to know what you’re looking at. If you don’t know the database schema and the actions taken by the application when it comes to correlation between the tables you’re pretty much taking a guess of what is actually obtained when you do a sql query. If you have your inner and outer joins incorrect in that query you might get different results as if you would have seen it via BNA itself and what is actually in the fabrics themselves.
Last week I had a request where an administrator wanted to obtain zoning info in order to pull that into a spreadsheet and have server admins be able to have a look at that. Now, let us be clear, neither Brocade nor any of the OEM’s support this so you cannot open cases/tickets with them in order to get help on this topic. If you really want, or need, to get direct DB access obtain a developers agreement with Brocade and get their API’s or even use SMI.
As far as normal access goes I would advise to create a separate profile in BNA and add the server admins in BNA and attach these (read-only) profiles to them. This will provide you much more granularity as well since youŕe able to restrict access to certain parts of your SAN environment. You won be able to do that with direct DB access.
Another reason you don’t want to do this is that you have to maintain your ODBC and/or web application yourself (if you’ve created one.) The database schema and/or table layout may change over certain versions. The BNA application itself is aware of that but your app may not. It could well be that a different normalization round between versions has found a more optimized data placement which you then have to figure out yourself.
So how do you provide this via BNA then?
First you have to create the users in BNA which you want to allow access plus configure the roles these users then play. The roles specify the privileges which a user has. Secondly you need to provide a, so called, AOR – Area of Responsibility. This sets the boundaries of your SAN where you want this particular user to so thing. So is a Windows administrator needs to see or do thing in the SAN you can restrict him to just that piece of the SAN environment and obviously you can do the same for other roles.
When you click on the Users icon this screen appears. As you can see I added a user called “RO”, I have a few (default) roles and a custom made “Zone View” role as well as a custom AOR called FAB40.
In the “Zone View” role I just provide read-only access to a few zoning capabilities.
And these two roles plus the AOR are then added to the RO user.
When you then log in under these credentials you’ll see the environment and management capabilities have been reduced to as what the options and AOR are configured.
You will also notice the majority of icons just below the menu bar have been greyed out. This is also because this particular user does not have the privileges for these functions as these roles are not attached to this profile.
So, as you see, it is fairly simple and certainly more convenient to create separate users with different roles and responsibilities in BNA itself to provide a nice overview and the required information than to start hacking in databases.
Hope this helps.