Since the persistent volume information was removed from the kubelets metric information. What is the best method of monitoring or checking free space on persistent volumes?
I'm running into an issue, I'm attempting to add users with the following ldif;
dn: mail=jsmith,ou=customers,dc=mydeqcust,dc=org
cn: John Smith
sn: Smith
uid: jsmith
mail: [email protected]
objectClass: inetOrgPerson
mail: jsmith
it adds fine, however when I look at the record, I see that it only has the attributes from inetOrgPerson, not orginzationalperson or person, even though I verified in the slapd.d schema's that they are properly inheriting. If I add the additional objectClass for each one it works fine.
My understanding was that openldap would automatically go through the hierarchy and add the additional classes. I'm running
root@LNX-mydeq-dev-ldap-02 tmp]# slapd -V
@(#) $OpenLDAP: slapd 2.4.39 (Aug 16 2014 20:41:55) $
I've been trying to figure out this problem for several weeks now, we are using an Exadata that runs nightly RMAN jobs to backup the database to a NFS mount. When these jobs occur, the average latency on our Fiber SAN goes through the roof. However, these are only a few thousand iops, 90% of the time, the rest of are infrastructure is running around 20k iops, so it's a drop in the bucket, and latency does not jump even during spikes. When I run tests against the same NFS server with dd operations, there is no increase in SAN latency.
We are running a Sparc Blade for the NFS server that has 8Gb fibre connections to a AMS SAN. The storage presented to that server is on SATA, but the latency is affecting our VMWARE, and Oracle systems that are on Fibre drives, and on a different controller.
I'm running out of ideas, has anyone else ever seen anything like this?
update 12/17
After doing some research, it looks like the mount options on the exadata are set to 32k transfer sizes for reads and writes. I'm working with the DB team to use some sane transfer sizes, however Oracle recommends 32k...
update 12/31
It was the NFS mount sizes, we upped them to a meg each, and also dropped the RMAN channels two 2 instead of 32( I have no idea what the dba's were thinking)
Recently we completed a new MSSQL cluster that we are planning on migrating all existing SQL databases to. This includes our Sharepoint databases, while looking into moving the databases I found the Microsoft documentation for moving Sharepoint 2007, however have not been able to find anything similar for Sharepoint 2003. Can anyone point me to a guide for moving the databases, or provide some tips, instructions or warnings? Thanks
In Nagios, assume the following scenario: you have 3 hosts, A B and C each with services 1-3, and having host B as a parent host to host C with A being at the same level as B.
Is it possible to; a) When scheduling downtime for host A, also have downtime scheduled for all services on that host? b) When downtime occurs, unexpected or otherwise on host B, have all service on host C be considered down also without alerts or notifications, like the host itself is?
Thanks