As you may guess, I was lucky enough to be selected as a Tech Field Day Delegate recently and being my first TFD I wasn’t sure what to expect from it, but let me tell you: it’s definitely the best way to hear and know about Enterprise IT products, there’s no Kool-Aid involved and you get to talk with top notch people.
A new thing for Tech Field Day was the hometown gift exchange that took place the night before starting the visits.
All the delegates were requested to bring something for each delegate from home that could represent their hometown and who they are, to better know each other and to break the ice with the other delegates, an awesome idea if you ask me!
Everybody brought something from their own homeland: we got candies, cards, bottle openers, books, shot glasses, coasters, everything has been awesome but not for the gift itself, but for the story behind it, and the story behind every delegate as everyone was brought up to talk about himself and distribute the gifts.
So if you’ve been selected as a Tech Field Day delegate and you’re reading this because you don’t know what to bring here’s a three-tip list for you:
Bring something for every delegate (or make sure that everyone could share what you brought).
Don’t spend too much on it (I spent approximately 9$/each).
Bring something that represents where you’re coming from or that has a meaning to you.
I would like to thank again Stephen and Matt for letting me be part of this, it’s been an awesome experience.
It’s been a long time since my last post, as you may already know I’ve been very busy obtaining the VCDX certification and I’ve been also knee deep in getting a new blog online: Juku.it
Me and Enrico decided to convey our blogging effort into a more open and agnostic form, without being tied to a specific vendor (I work as Architect at a small consulting firm called Cinetica) and so Juku was born, as told in the “Why Juku?” section Jukus are private Japanese schools and they’re intended to help students improve performance in their regular school work and to help them better prepare for exams, and that’s precisely our goal, not to replace the traditional information channels, but to augment them with our opinions in the more unbiased manner possible.
I will continue to post the more technical articles and my personal thoughts on P2V It! so don’t just unsubscribe it
DISCLAIMER: I work for a Company which is a Compellent Business Partner, we sell and provide consultancy services on Compellent products.
Given my job, I deal every day with VMware customers, and, at least in Italy, the most misunderstood and mishandled aspect of a virtual infrastructure is the storage part.
VMware introduces another powerful layer on top of the already complex SAN scenario and this often confuse the customers even more, in order to mitigate this several big storage names (NetApp and EMC in primis) created plugins to seamlessly manage storage directly from the familiar vSphere client, hiding many of the repetitive and sometimes complex tasks.
Compellent may not be the first at the game but they surely took an interesting approach, they provide integration at both ends of the storage stack.
In fact you can provision and manage the storage from a vSphere plugin (expected to be GA during Q4) or you can do the same from Enterprise Manager, which is the management interface for your Compellent storage infrastructure (provides a single pane-of-glass on all your Compellent systems).
This approach in my opinion gives you a great degree of flexibility, if you’re a storage guy and you’re in charge to provide storage to your company’s VMware infrastructure you can use your familiar storage GUI to provision storage at the Datastore level and if you’re a multiple-caps IT guy, you can use the vSphere client to do the same with a simple wizard, without getting your hands dirty inside the storage interface.
Below you can find a couple of videos showing the integration at both ends:
Last week I updated my old WWN Decoder page (renamed as “Storage Tools“) with three useful storage widgets: RAID Space Calculator, a RAW IOPS Calculator and a Replication Bandwidth Calculator.
The IOPS calculator is a bit simplistic right now, I’m trying to improve it to include latency and other determining factors in the IOPS calculation.
Couple of weeks ago I was preparing a demo lab for a technology event held by my company here in San Marino and I had to join a couple of NetApp filers to an Active Directory environment.
The process itself is very simple but there are a couple of things to keep in mind regarding the time so I thought it would be nice to share them.
Before starting, here’s a bit of background on why clock is very important:
Active Directory authentication is based on a protocol called Kerberos, which use a ticketing system to grant access, the system time is very important because:
[...] In order to prevent intruders from resetting their system clocks in order to continue to use expired tickets, Kerberos V5 is set up to reject ticket requests from any host whose clock is not within the specified maximum clock skew of the KDC. Similarly, hosts are configured to reject responses from any KDC whose clock is not within the specified maximum clock skew of the host. The default value for maximum clock skew is 300 seconds, or five minutes. [...]
So, basically, if the system clock of a machine is not within the 5 minutes range, the Kerberos system deny the authentication saying “clock skew too great”.
In order to avoid this we need to make sure that our NetApp FAS is within the acceptable range because even the join cannot complete if the clocks are not aligned, so first of all, issue a date command with this syntax:
demo02>date201002171454
Warning: syncing time to an external timesourcewhich will eventually override the timeset by the date command.
201002171425 which is (YYYYMMDDhhmm) means:
February, 17th 2010 2:54pm
And then we need to configure the NTP server to keep the time in sync with the Domain Controllers:
demo02> options timed.enable off
demo02> options timed.proto ntp
demo02> options timed.servers <NTP SERVER ADDRESS>
demo02> options timed.max_skew 5m
demo02> options timed.enable on
Now you can proceed with the domain join which is a very simple wizard-like interactive procedure, the command is cifs setup and here you can find a transcript:
demo02> cifs setup
This process will enable CIFS access to the filer from a Windows(R) system.
Use "?"forhelp at any prompt and Ctrl-C to exit without committing changes.
Your filer does not have WINS configured and is visible only to
clients on the same subnet.
Do you want to make the system visible via WINS? [n]:
A filer can be configured for multiprotocol access, or as an NTFS-only
filer. Since multiple protocols are currently licensed on this filer,
we recommend that you configure this filer as a multiprotocol filer
(1) Multiprotocol filer
(2) NTFS-only filer
Selection (1-2)? [2]: 2
CIFS requires local/etc/passwd and /etc/group files and default files
will be created. The default passwdfile contains entries for'root',
'pcuser', and 'nobody'.
Enter the password for the root user []:
Retype the password:
The default name for this CIFS server is 'DEMO02'.
Would you like to change this name? [n]:
Data ONTAP CIFS services support four styles of user authentication.
Choose the one from the list below that best suits your situation.
(1) Active Directory domain authentication (Active Directory domains only)(2) Windows NT 4 domain authentication (Windows NT or Active Directory domains)(3) Windows Workgroup authentication using the filer's local user accounts
(4) /etc/passwd and/or NIS/LDAP authentication
Selection (1-4)? [1]: 1
What is the name of the Active Directory domain? [HANDS-ON.LOCAL]: HANDS-ON.LOCAL
In order to create an Active Directory machine account for the filer,
you must supply the name and password of a Windows account with
sufficient privileges to add computers to the HANDS-ON.LOCAL domain.
Enter the name of the Windows user [Administrator@HANDS-ON.LOCAL]: Administrator@HANDS-ON.LOCAL
Password for Administrator@HANDS-ON.LOCAL:
CIFS - Logged in as Administrator@HANDS-ON.LOCAL.
The user that you specified has permission to create the filer's
machine account in several (2) containers. Please choose where you
would like this account to be created.
(1)CN=computers
(2)OU=Domain Controllers
(3) None of the above
Selection (1-3)? [1]: 1
CIFS - Starting SMB protocol...
It is highly recommended that you create the local administrator
account (DEMO02\administrator)for this filer. This account allows
access to CIFS from Windows when domain controllers are not
accessible.
Do you want to create the DEMO02\administrator account? [y]:
Enter the new password for DEMO02\administrator:
Retype the password:
Currently the user "DEMO02\administrator" and members of the group
"HANDS-ON\Domain Admins" have permission to administer CIFS on this
filer. You may specify an additional user or group to be added to the
filer's "BUILTIN\Administrators" group, thus giving them
administrative privileges as well.
Would you like to specify a user or group that can administer CIFS? [n]: n
Welcome to the HANDS-ON.LOCAL (HANDS-ON) Active Directory(R) domain.
CIFS local server is running.
As you can see it’s a really simple and straightforward process, and you can even fire up compmgmt.msc from your Windows box and point it to the NetApp to see and map shares!.
