To add a new disk into a DN/NM config is as easy as configuring their data.dirs/local-dirs keys to the path the disk is mounted as. To change log dirs, you can use CM configuration fields to set newer locations, or alternatively move the log dirs and create symlinks to the new paths from the original. Does this help? ... View more

The preferred way to test a cross-realm auth (in CDH context) is to try and obtain a cluster realm's service ticket when logged in as the remote realm. kinit user@REMOTEREALM kvno hdfs/namenode-host@LOCALREALM If the service ticket obtaining fails, then Cross Realm Trust is broken. A lot of people also oversee/misconfigure [domain_realm]. It exists to mean an automatic mapping of hostnames to their realms, and it factors greatly into the use of cross-realm trust when dealing with service authentication. An ideal [domain_realm], if you have two cluster realms A (host1.a.com, host2.a.com) and B (mybhost.data.com, mychost.data.com) would look like: [domain_realm] host1.a.com=A host2.a.com=A mybhost.data.com=B mychost.data.com=B Or if you use the limited wildcard ability, if applicable range-wise: [domain_realm] .a.com=A .data.com=B This section helps Kerberos libraries and clients to find the right KDC to talk to when looking for a server under a specific realm (its the intelligence mapping that helps determine which service host lies in what realm). Another thing to remember is that the communication isn't done in fallback manner. The trust works based on the key being the same on both ends (For the krbtgt principals). That is, an encrypted token generated on one end may be trusted on another end if it can decrypt it (and since you use the same key on both sides, this is possible). The path of communication therefore is purely dependent on reaching the correct KDC for the provided principal - something [domain_realm] would help with. Does this help? ... View more

Unless your NameNode is down, the only other reason, minus firewalls/etc. misconfigs, is that the NameNode port (and maybe other services' ports) are listening on a different network interfaces than the internal IP one. You could verify this with netstat on the refusing service's host. ... View more

A few points: 1. Remote/non-short-circuit-local block reads are done via the DN IPC port (50010 or 1004), and not via local filesystem, so HDFS clients of any form will never require local permission access to the block files. The DN reads and streams the data. Same applies for writes. 2. Local short circuit reads, if enabled and applicable, are done in a secure manner via use of Unix Socket Domains. The DN opens the file and passes the file descriptor to the client, bypassing the need for clients to be able to read block file paths directly. ... View more

Given a fully used situation with preemption disabled, B will begin running as soon as A's containers complete (as opposed to waiting the A application to end entirely before it runs). ... View more